A Primer

Applying a

Regional ITS Architecture

to Support Planning for Operations
Quality Assurance Statement

The Federal Highway Administration (FHWA) provides high-quality

information to serve Government, industry, and the public in a manner that

promotes public understanding. Standards and policies are used to ensure and

maximize the quality, objectivity, utility, and integrity of its information. FHWA

periodically reviews quality issues and adjusts its programs and processes to

ensure continuous quality improvement.

Notice

This document is disseminated under the sponsorship of the Department of

Transportation in the interest of information exchange. This United States 

Government assumes no liability for its contents or use thereof. This report 

does not constitute a standard, specification, or regulation.
Technical Report Documentation Page

1. Report No.

7. Author(s)

17. Key Words

19. Security Clasif. (of this report)

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized

20. Security Clasif. (of this page) 21. No. of Pages 21. Price

4. Title and Subtitle

15. Supplementary Notes

16. Abstract

9. Performing Organization Name and Address

12. Sponsoring Agency Name and Address

5. Report Date

10. Work Unit No. (TRAIS)

13. Type of Report and Period Covered

6. Performing Organization Code

11. Contract or Grant No.

14. Sponsoring Agency Code

8. Performing Organization Report No.

18. Distribution Statement

FHWA-HOP-12-001

Applying a Regional ITS Architecture to Support Planning for Operations: A Primer

Mr. Jim Hunt and Mr. Wayne Berman, Federal Highway Administration, COTM

This primer offers transportation planners and operations managers a menu of opportunities for applying the regional ITS architecture to 

enhance planning for operations. It provides specific entry points for leveraging the regional ITS architecture in integrating operations into the 

planning process. This primer centers on the use of an objectives-driven, performance-based approach to planning for operations; an approach 

that can leverage regional ITS architectures given the approach’s emphasis on operational objectives and performance measures and the 

architecture’s use of data and services to address operational needs. Additionally, the primer leads planners and operators through techniques 

to make a regional ITS architecture relevant and more accessible to practitioner needs in planning for operations. 

Science Applications International Corporation (SAIC)

8301 Greensboro Drive

McLean, VA 22102

R. C. Ice and Associates

27155 Big Horn Mountain Way

Yorba Linda, CA, 92887

United States Department of Transportation

Federal Highway Administration

1200 New Jersey Ave., SE

Washington, DC 20590

Ronald C. Ice, Jocelyn K. Bauer (SAIC), William R. Loudon (DKS), Kevin Fehon (DKS)

Planning for operations, regional ITS architecture, operations, 

management and operations, operations objectives, performance 

measures, technology.

No restrictions.

Unclassified Unclassified 100 N/A

February 2012

DTFH61-06-D-00005

HOP

2. Government Accession No. 3. Recipient’s Catalog No.

DKS Associates

1970 Broadway, Suite 740

Oakland, California 94612-2219
Acknowledgements

The development of this Primer greatly benefited from the contributions of practitioners from 

metropolitan planning organizations, State and local departments of transportation, transit 

agencies, and professional associations. In particular, FHWA and the authors acknowledge 

the members of the peer review panel who provided input throughout the primer development.

Abed Abukar, Dallas Area Rapid Transit

Elizabeth Birriel, Florida Department of Transportation

Rashmi Brewer, Minnesota Department of Transportation

Rich Denbow, Association of Metropolitan Planning Organizations

Bruce Eisenhart, ITS America Cross-Cutting Issues Forum

Chris Francis, Virginia Department of Transportation

Lacy Love, American Association of State Highway and Transportation Officials

Leo Luo, Maricopa Association of Governments

Matt Hardy, American Association of State Highway and Transportation Officials

Nathan Masek, Mid-Region Council of Governments

Amy McElwain, Virginia Department of Transportation

Rita Morocoima-Black, Champaign Urbana Urbanized Area Transportation Study

Keith Nichols, Hampton Roads Transportation Planning Organization

Doug Noble, Institute of Transportation Engineers

Deena Platman, Oregon Metro

Stan Platt, Delaware Valley Regional Planning Commission

Denny Pretash, Pennsylvania Department of Transportation

Camelia Ravanbakht, Hampton Roads Transportation Planning Organization

Alan Thompson, Southern California Association of Governments

Doug Tomlinson, Pennsylvania Department of Transportation

John Toone, King County, Washington

James Witherspoon, Virginia Department of Transportation

Albert Yee, Metropolitan Transportation Commission, California
Dear Colleague,

The Federal Highway Administration’s (FHWA) Office of Planning, Environment, and Realty, 

Office of Operations, the Federal Transit Administration’s (FTA) Office of Planning and 

Environment, and the Research and Innovative Technology Administration ITS Joint Programs 

Office are pleased to present this primer on Applying the Regional ITS Architecture to Support 

Planning for Operations.

A number of resources have been produced over the last few years by FHWA and FTA to advance 

operations thinking in the transportation planning process. In particular, guidance, best practices, 

and examples have been developed and used to illustrate how an objectives-driven, performancebased approach could be applied to integrate management and operations strategies and programs 

into metropolitan and statewide transportation plans. This approach forms the basis for the Planning 

for Operations initiatives.

Another aspect of the joint FHWA and FTA guidance is to facilitate the sustained application 

and use of the Regional ITS Architectures. The Regional ITS Architectures are another tool that 

can be used to help mainstream operations into the planning process. 23 CFR 940.5 requires that 

Regional ITS Architectures be “consistent with the transportation planning process for Statewide 

and Metropolitan Transportation Planning” and that a broad cross section of agencies involved in 

transportation operations, including highway agencies, public safety agencies, transit operators, and 

others be included in the architecture development process. Since the Architecture requirement took 

effect in 2005, over 300 regional ITS Architectures have been developed and many continue to be 

updated in accordance with Federal requirements.

The benefits derived by agencies from coordinating elements of the planning for operations 

approach with regional ITS architectures are the motivation for this primer. The regional ITS 

architecture can provide a technical framework for regional operations integration, information 

sharing, and data to support performance monitoring. By reviewing architecture documents and 

conducting in-depth planning practitioner interviews, the primer offers transportation planners and 

operations managers a menu of opportunities for applying the regional ITS architecture to enhance 

planning for operations.

Some of the areas where Regional ITS Architectures can enhance planning for operations include: 

improving collaboration between regional planning and operations practitioners, improving 

project scoping, improving traceability between regional objectives and operational strategies, and 

improving integration and coordination across agencies and systems. This primer, which continues 

the strong collaboration among FHWA, FTA, and professionals in the planning and operations 

communities nationwide, can be accessed electronically by visiting the USDOT website on 

Planning for Operations at http://www.plan4operations.dot.gov. 
We look forward to receiving your feedback, reactions, and experiences in implementing the 

recommendations in the Primer. Please direct any comments, questions, and suggestions to any of 

the following members of our staff:

James T. Hunt at jim.hunt@dot.gov, 717-221-4422

Egan Smith at egan.smith@dot.gov, 202-366-6072; or

John Sprowls at john.sprowls@dot.gov, 202-366-5362.

Sincerely yours,

2
iii

Contents

vii Executive Summary

1 Chapter 1: Introduction

1 1.1 The Motivation

3 1.2. How to Use This Primer

5 Chapter 2: Planning for Operations and Architecture – A Quick Tutorial

5 2.1. Operations and ITS – A Unified View

6 2.2. What is Planning for Operations?

9 2.3. What is a Regional ITS Architecture?

13 2.4. Making the Connections

21 Chapter 3: Opportunities for Architecture Use

22 3.1. Establishing Collaboration and Coordination

24 3.2. Developing Goals, Operations Objectives, and Performance Measures

29 3.3. Determining Operations Needs

32 3.4. Identifying, Evaluating, and Selecting M&O Strategies

34 3.5. Defining Programs and Projects

38 3.6. Selecting and Prioritizing Projects

43 3.7. Implementation and System Operations

45 3.8. Monitoring and Evaluation

49 Chapter 4: Creating a Planning-Supportive Architecture

49 4.1. Making the Architecture Connections to Planning Explicit

56 4.2. Keeping it Planner-Friendly

58 4.3. Adding the Planning Context – ITS/Operations Plans

64 4.4. Scheduling Updates to Optimize Use

67 Chapter 5: Your Action Plan for More Productive Architecture Use

67 5.1. Establish Support

67 5.2. Self-Assessment

70 5.3. Take Action

73 Appendix A: Turbo Architecture

77 Appendix B: Regulatory Requirements

77 1.1. Management & Operations and Architecture in the Planning Process 

79 2.1. Transportation Systems Management and Operations

80 3.1. Congestion Management Process

83 4.1. ITS Architecture and Standards
iv

Figures

viii Figure 1: Regional ITS Architecture Use in Planning for Operations.

2 Figure 2: A regional ITS architecture helps move regions from piecemeal improvements to 

integrated transportation solutions.

4 Figure 3: This Primer is Intended to Bring Together Two Audiences.

5 Figure 4: ITS Technology Supports Operations.

8 Figure 5: An Objectives-Driven, Performance-Based Approach to Planning for Operations.

10 Figure 6: A High-Level ITS Architecture.

11 Figure 7: Example of Interfaces between Elements.

11 Figure 8: Illustration of a Service Package.

11 Figure 9: Illustration of Project Sequencing.

12 Figure 10: Regional ITS Architecture Development Process.

14 Figure 11: Diagram Depicting Scenario A: Regional ITS Architecture Updated Prior to the 

Metropolitan/Statewide Transportation Plan Update.

15 Figure 12: Hypothetical Example of Where the Regional ITS Architecture Assists Planning in 

Specific Operations Areas.

16 Figure 13: Diagram Depicting Scenario B: Regional ITS Architecture Updated After the 

Metropolitan/Statewide Transportation Plan Update. 

17 Figure 14: Diagram Depicting Scenario C: Regional ITS Architecture Updated at the Same 

Time as the Metropolitan/Statewide Transportation Plan Update.

26 Figure 15: Minnesota Statewide Transportation Plan to Architecture Mapping.

28 Figure 16: Diagram Illustrating the Potential Data Sources Available to the Northwest 

Arkansas MPO.

31 Figure 17: Identifying and Filling the Gaps in the Phoenix Metropolitan Center to Center 

CCTV Network.

35 Figure 18: San Diego Intermodal Transportation Management System High-Level 

Architecture.

37 Figure 19: Using Service Package Customization to Define Projects in the Maricopa 

Association of Governments Regional ITS Architecture.

41 Figure 20: Excerpt from Project Proposal Template in the 2009 Virginia DOT’s Northern 

Virginia Operations Planning Guide: Leveraging ITS Architecture and Systems 

Engineering.

42 Figure 21: The Systems Engineering "V" Model.

43 Figure 22: Using the Regional ITS Architecture to Support Project Development.

51 Figure 23: Key Connections in the Context of the Planning and Architecture Processes.

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

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

55 Figure 26: MRCOG Regional ITS Infrastructure Geodatabase.

58 Figure 27: An ITS/Operations Plan Can Connect the Regional ITS Architecture with the 

Region's Transportation Plan and Program. 
v

Tables

25 Table 1: Hypothetical Example Showing Linkage Between Operations Objective 

and Strategies from Choices 2035 Champaign Urbana Urbanized Area 

Transportation Study Long Range Transportation Plan to Potential Regional ITS 

Architecture Service Packages.

39 Table 2: Memphis Regional ITS Architecture Projects Related to Incident Management.

50 Table 3: Planning to Architecture Connections.

56 Table 4: Techniques for Making the Architecture Planner-Friendly.

65 Table 5: Architecture and Transportation Plan Update Scheduling Options.

68 Table 6: Self-Assessment for Use of Regional ITS Architecture in Planning for Operations.

59 Figure 28: Adding Planning Context with an ITS/Operations Plan.

61 Figure 29: MDOT/SEMCOG ITS Deployment Plan - Livingston County Proposed ITS 

Deployments.

62 Figure 30: VDOT ITS Decision Support Tool - Cost and Benefit Data 

63 Figure 31: Connecting an RCTO, a Plan, and an Architecture.

64 Figure 32: Architecture Updates to Support Planning.

66 Figure 33: Excerpt from AMPA Regional ITS Architecture Addendum

67 Figure 34: Three Leverage Points for Capability Improvement.

68 Figure 35: Architecture Use for Planning Capability Levels

73 Figure 36: Turbo Architecture Uses the National ITS Architecture

74 Figure 37: Turbo Architecture Tabbed Interface - The Planning Tab,

75 Figure 38: Turbo Architecture Provides Many Output Options.

76 Figure 39: A Closer Look at the Right Side of the Planning Tab.
vi

Acronyms

ADMS Archived Data Management Subsystem

ATDM Active Transportation and Demand Management

ATM Active Traffic Management

CAD Computer-Aided Dispatch

CCTV Closed-Circuit Television

CFR Code of Federal Regulations

CMP Congestion Management Process

DOT Department of Transportation

FHWA Federal Highway Administration

FSP Freeway Service Patrol

FTA Federal Transit Administration

GPS Global Positioning System

ICM Integrated Corridor Management

ITS Intelligent Transportation Systems

LRSTP Long-Range Statewide Transportation Plan

M&O Management and Operations

MPO Metropolitan Planning Organization

MTP Metropolitan Transportation Plan

RCTO Regional Concept for Transportation Operations

SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act: 

A Legacy for Users

STIP Statewide Transportation Improvement Program

TIP Transportation Improvement Program

TMC Transportation Management Center

TOC Traffic Operations Center

TSM&O Transportation Systems Management and Operations
Applying a Regional ITS Architecture to Support Planning for Operations vii

Executive Summary

Effectively integrating management and operations (M&O) into the metropolitan and 

statewide transportation planning processes requires significant inter-agency 

collaboration and a regional view of the area’s multimodal transportation system. 

Because many M&O strategies are underpinned by intelligent transportation systems 

(ITS), the coordination of planning for ITS among agencies at the institutional and 

technical level is an essential element to planning for operations. The regional ITS 

architecture, with a focus on integrating transportation services supported by ITS, 

presents a significant opportunity to support the needs for effective planning for 

operations. 

This primer offers transportation planners and operations managers a menu of 

opportunities for applying the regional ITS architecture to enhance planning for 

operations. It provides specific entry points for leveraging the regional ITS architecture 

in integrating operations into the planning process. This primer focuses on the use of 

an “objectives-driven, performance-based” approach to planning for operations; an 

approach that increases the potential support from the regional ITS architecture given 

the approach’s emphasis on data and performance measures. Additionally, the primer 

leads planners and operators through techniques to make a regional ITS architecture 

relevant and easy-to-use in planning for operations. 

Why leverage the regional ITS architecture for planning for 

operations?

Integrate and coordinate the technology underlying operations services: Planning 

for operations without the support of a regional ITS architecture risks poor integration of 

ITS across the region. The regional ITS architecture facilitates the integration and 

coordination of compatible ITS across a region so that related projects are implemented 

more efficiently and travelers experience seamless transportation services as they travel 

across multiple jurisdictions. 

Align efforts to make greater progress in ITS and operations: By aligning the 

regional ITS architecture with the operations goals, operations objectives, and 

management and operations strategies in the metropolitan or statewide transportation 

plan, planning for operations and the regional ITS architecture can reinforce each other 

and make greater strides together toward improving safety, efficiency, and reliability. 

Use existing resources smartly: A regional ITS architecture that does not support 

metropolitan or statewide planning, programming, and implementation of operations 

programs and projects has an extremely limited impact after the initial collaborative 

benefits of regional ITS architecture development fade. This represents a significant 

The regional ITS 

architecture helps

answer the following 

important questions:

5 What M&O strategies 

supported by ITS may be 

available to help achieve 

our operations objectives?

5 What data is available in 

our region to monitor 

transportation system 

performance and track 

progress toward 

operations objectives?

5 What are the gaps in 

providing transportation 

system management and 

operations across our 

region?

5 How can we most 

effectively integrate a new 

M&O strategy supported 

by ITS with other existing 

or planned technology 

deployments to provide a 

greater level of service for 

the customer?

5 How can we define an 

M&O project or program 

in terms of functional 

requirements, operations 

concepts, supporting ITS 

standards, etc.?

Executive Summary
viii

opportunity loss. Connecting the architecture to planning 

reduces the duplication of effort that goes into both 

developing the regional ITS architecture and planning for 

operations. This primer shows the parallels between the 

processes and how to take advantage of them. This is 

particularly important for smaller and less complex 

regions and regions with scarce resources. 

How does the regional ITS architecture 

support

planning for operations? 

The regional ITS architecture can provide support in 

almost all areas of the objectives-driven, performancebased approach to planning for operations as shown in 

Figure 1. The Federal Highway Administration (FHWA) 

and the Federal Transit Administration (FTA) recommend 

the use of an objectives-driven, performance-based 

approach as an effective way to integrate operations in 

the metropolitan and statewide transportation planning 

processes. The approach focuses on the use of specific, 

measurable, and outcome-oriented operations objectives to guide the planning and programming of M&O. 

Opportunities to leverage the regional ITS architecture in support of planning for 

operations include:

 Sustain and build on the collaborative relationships from the regional ITS 

architecture development.

 Consult the architecture to identify available sources of operations data to track 

measurable objectives.

 Gather information on operations needs from the architecture and ITS 

stakeholders.

 Examine service packages in architecture when identifying ITS-based M&O 

strategies.

 Include the architecture as part of the transportation improvement program (TIP) 

development process.

 Use the architecture’s operational concepts, functional requirements, and other 

contents to kick-start project development.

Figure 1: Regional ITS Architecture Use in Planning for Operations.

Regional Collaboration and Coordination

Regional 

ITS Architecture

Metropolitan or Statewide 

Transportation Plan

Implementation/System Operations

Define Performance Measures

Determine Operations Needs

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Operations Objectives

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Regional Goals and Motivation

Monitoring and Evaluation

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Executive Summary
Applying a Regional ITS Architecture to Support Planning for Operations ix

In order to realize these opportunities and achieve the greatest benefit, the regional ITS 

architecture may require an update so that it is current and supports the intended use. 

Updating the regional ITS architecture to support planning for operations enables 

planners and operators to more easily access the relevant portions of the architecture 

and take advantage of the opportunities identified in this primer. Explicitly documenting 

the connections between the planning for operations and the regional ITS architecture will 

help link the efforts. Additionally, the development of an operations or ITS plan may be an 

effective way to bridge the gap between the metropolitan or statewide plans and the 

regional ITS architecture. An operations or ITS plan provides a collaborative strategy for 

implementing operations and ITS projects and programs over time and operating and 

maintaining an integrated transportation system. While there are a number of actions that 

a region can take to use the regional ITS architecture to support planning for operations, it 

is important to focus first on creating an architecture that is ready for use and taking steps 

toward those opportunities that will bring the greatest benefit to the region’s planning for 

operations effort. Using the regional ITS architecture will result in more efficient, effective, 

and collaborative implementation of ITS-based operations strategies to improve 

transportation system performance.

Executive Summary

Applying a Regional ITS Architecture to Support Planning for Operations 1

1 Introduction

1.1 The Motivation

Transportation professionals find themselves under ever-increasing pressure to do more 

with less in the face of shrinking budgets, increasing demand for transportation services, 

and mounting customer expectations from coast to coast. At the same time, ongoing 

rapid advances in technology create new opportunities to operate the transportation 

system in a safer and more efficient manner. While technology represents tremendous 

opportunity for enhancing management and operation of the transportation system, it also 

entails challenges, particularly from a planning perspective. Planning efficient, 

collaborative operations strategies enabled by technology requires the use of a regional 

intelligent transportation system (ITS) architecture to provide the greatest level of 

customer service with cost-effective and regionally integrated solutions.

Planning for operations seeks to integrate 

management and operations (M&O) into the 

metropolitan and statewide transportation 

planning processes. It focuses on accomplishing 

consensus-based regional outcomes for the 

performance of the regional transportation 

system through the use of M&O rather than 

developing individual projects. Operations 

activities are moving from stand-alone, local 

projects to regional solutions that require 

collaboration and integration. Since many M&O 

strategies rely on technology, the regional ITS 

architecture is an essential tool in supporting the 

integration of M&O strategies across a region to 

accomplish these regional outcomes. 

The architecture puts each of the strategies in a regional context, resulting in more 

cost-effective solutions and ultimately more seamless service across jurisdictional 

boundaries. It defines how a region can most effectively integrate new strategies that 

include ITS with other existing or planned technology deployments to provide a greater 

level of service for the customer. 

Planning for technology-based operations activities is fundamentally different than 

planning for traditional capital infrastructure projects. No one has the foresight to 

accurately forecast progressive technology innovation over a 20-year timeframe in a 

metropolitan or statewide transportation plan, but we know that the technology 

innovation will occur. We also know that individual systems will become more 

intelligent and increasingly integrated over time. The most advanced systems that are 

A regional ITS architecture 

is a framework for institutional 

agreement and technical 

integration in a particular region. 

The architecture defines the links 

between the pieces of the system 

and the information that is 

exchanged on each connection. 

Over 300 regional ITS 

architectures have been developed 

so chances are good that you 

already have one in your region.

A region is considered to be any 

multi-jurisdictional area defined by 

the needs of the collaborating 

agencies.

The architecture gets you

one step ahead...The 

architecture has helped us 

build out projects here and I 

believe we have gotten far 

more than our money’s worth 

out of it.

Peter Thompson

San Diego Association of 

Governments (California) 

The architecture defines the 

value and degree of 

integration that is possible 

among stakeholders involved 

in planning and operations.

Nathen Masek

Mid Region Council of

Governments

(Albuquerque, NM)

The ITS architecture, along 

with the ITS Strategic Plan, 

has assisted in defining 

projects and the connections 

between various projects and 

stakeholders.

Keith Nichols

Hampton Roads

Transportation Planning

Organization

(Hampton Roads, VA)

chapter 1 introduction
2

currently being implemented – Active Transportation and Demand Management 

(ATDM), Integrated Corridor Management (ICM), and regional traveler information 

systems are all predicated upon effective integration between systems at a technical 

level and between organizations at an institutional level. Next generation systems will 

continue the progression toward increasing integration of intelligent systems, including 

mobile devices that will offer a better understanding of transportation operations 

performance and more effective communication with transportation customers. The 

regional ITS architecture is a tool that is specifically designed to support planning for 

integration among these intelligent systems, organizations, and customers. Even for 

smaller or less complex regions, using the regional ITS architecture to support 

planning for operations has substantial benefits including a reduction of duplicative 

efforts and increased leverage of existing and planned ITS and data resources across 

the region. 

Using the regional ITS architecture results 

in a collaborative process for fitting the 

pieces of the transportation system together 

in a more integrated and compatible way. 

Building on the holistic “all modes and all 

roads” integrated framework of the 

architecture provides tangible benefits for 

planners, operators, and the transportation 

system. This primer provides useful 

guidance for how use of the regional ITS 

architecture can enrich that planning for 

operations activity and achieve the next big 

step in regional compatibility. 

A regional ITS architecture documents the interrelationships between ITS applications 

within a region and provides a structure for enhancing those relationships. By applying 

the regional ITS architecture in planning for operations, these interrelationships can be 

recognized and a more efficient and effective system of operational strategies 

achieved. Rather than competing for funding to implement piecemeal improvements, 

agencies can use the architecture to collaboratively develop a more integrated set of 

regional solutions. 

The regional ITS architecture can also be used to identify the data that is available in the 

region to monitor transportation system performance and track progress toward 

operations objectives that are central to the objectives-driven, performance-based 

approach to planning for operations. The architecture provides an ideal framework for 

identifying these data sources and planning the monitoring systems that can be used to 

measure performance for the region’s congestion management process or other datadriven transportation planning activity.

Although there are significant benefits, there can also be challenges in applying a 

regional ITS architecture in planning for operations. This primer provides useful 

I think that one of the biggest 

benefits for us is seeing on 

paper how many different 

people are involved. We have 

been able to focus on what 

our end goal is as traffic 

engineers and have a 

roadmap of how to get from 

where we are to where we 

want to be. It is a constant 

reminder that more people 

need to be involved in the 

planning process than just us.

Debbie Albert

City of Glendale, AZ

The architecture is an 

inventory of elements, 

linkages of the elements and 

data exchanges, and 

stakeholders. All of this 

knowledge assists with 

improving planning, 

implementation and 

reducing project risk.

Tom Bruff

Southeast Michigan

Council of Governments 

(Detroit, MI)

Lesson Learned. Several issues can 

result from NOT using the architecture. 

For example, a county road commission 

recognized the value of the architecture 

only after encountering a series of 

challenges in coordinating signal control 

along a major corridor between the 

county, the State and several cities. 

More proactive participation as the 

regional ITS architecture was developed 

would have better aligned individual 

agency plans and greatly facilitated this 

process.

Integrated

Solutions

Piecemeal

Improvements

Figure 2: A regional ITS architecture helps 

move regions from piecemeal improvements 

to integrated transportation solutions.

chapter 1 introduction
Applying a Regional ITS Architecture to Support Planning for Operations 3

recommendations on how those challenges can be overcome. The professionals who 

are responsible for transportation planning in a region are often different than those who 

are responsible for operations, and using the architecture in transportation planning 

requires ongoing collaboration between these practitioners. Although the regional ITS 

architecture initially brought together the planning and operations professionals to work 

collaboratively in many regions, that working relationship has not always been sustained. 

In other regions, the regional ITS architecture was developed by a consultant with a 

regional committee providing oversight and so the collaboration may have been limited in 

scope. Other challenges for applying the regional ITS architecture in planning for 

operations may be limited resources for additional planning efforts in a region or 

differences in the timing of the cycles of operations planning and ITS architecture 

updates. This primer provides recommendations for how these types of challenges can 

be overcome.

Finally, the regional ITS architecture can 

provide an entry point to project development 

and systems engineering and standards. For 

these implementation steps, developers of 

operational strategies within a region can draw 

on the architecture to provide initial input to 

these processes. While this primer is not 

intended as a guidance document for 

implementation of operational strategies, 

understanding the needs can help in seeing 

operational strategies though to successful 

programming, design, and integration. 

Referencing the regional ITS architecture can 

help provide that understanding.

1.2. How to Use This Primer

This primer includes five chapters that are organized to introduce you to the key 

concepts of planning for operations and regional ITS architectures and then to 

describe how the regional ITS architecture can be used to improve planning for 

operations. The primer is organized to be read front to back as each chapter builds on 

concepts presented in the previous chapter, but feel free to skip around and sample 

content, particularly if you already have some background in planning for operations 

and regional ITS architectures.

This primer is written for two audiences: 1) Transportation planning and operations 

staff and consultants who are involved in planning for operations and, 2) staff and 

consultants that are involved in regional ITS architecture development, use, and 

maintenance. In many cases, there is overlap between these audiences, and indeed, 

our intent is to increase the overlap since planning for operations and regional ITS 

architecture activities should build upon one another. To support the dual audience, 

One last bit of motivation:

Recognizing the benefits of 

architecture use in planning, 23 CFR 

450.306(f) states: “The metropolitan 

transportation planning process shall 

(to the maximum extent practicable) 

be consistent with the development 

of applicable regional intelligent 

transportation systems (ITS) 

architectures, as defined in 23 CFR 

part 940.”

23 CFR 450.208(f) levies a similar 

requirement on the statewide 

transportation planning process.

chapter 1 introduction
4

the primer bounces back and forth between the two perspectives. 

Whether you are a transportation planner, an ITS engineer, or an 

operations practitioner, this primer will help you to understand how a 

regional ITS architecture can be used to make planning for operations 

more effective and efficient. 

Here is a breakdown of the remaining chapters and appendices and what 

you will find in each:

Chapter 2: Planning for Operations and Architecture – A Quick 

Tutorial – This is the place to start if you need some background in the 

objectives-driven, performance-based approach to planning for 

operations or the regional ITS architecture. The last part of this chapter 

explores the relationship between planning for operations and 

architecture, which is new material that may be helpful even for those who 

are well versed in both processes.

Chapter 3: Opportunities for Architecture Use – This chapter looks in detail at the 

opportunities to use the regional ITS architecture to support planning for operations. With 

a decided planning for operations perspective, the chapter steps through the planning for 

operations approach and identifies how the regional ITS architecture can be used at each 

step.

Chapter 4: Creating a Planning-Supportive Architecture – This chapter is written 

more from the regional ITS architecture perspective. Given the opportunities for 

architecture use explained in Chapter 3, this chapter identifies how the architecture can 

be improved to better support those opportunities. This chapter also covers ITS strategic 

plans and regional concepts for transportation operations (RCTOs) and their role in 

supporting planning for operations and architecture. Finally, this chapter provides 

guidance on the relative scheduling of transportation plan and architecture updates.

Chapter 5: Your Action Plan for More Productive Architecture Use – This chapter 

describes the process improvement steps that will institutionalize architecture use in the 

transportation planning process in your region. It defines a process that builds 

decisionmaker support, assesses current architecture use, and plans the necessary 

steps to make architecture use more efficient and productive.

Appendix A: Turbo Architecture – This appendix provides a quick introduction to the 

Turbo Architecture software that is used to create, maintain, and use regional ITS 

architectures with particular focus on the features in the software that support planning for 

operations. 

Appendix B: Regulatory Requirements – This appendix includes excerpts from 

SAFETEA-LU,Title 23 CFR 450, and Title 23 CFR 940 that are related to management 

and operations planning and use of ITS architectures to support planning.

Figure 3: This Primer is Intended to Bring Together Two Audiences.

People Involved in

Planning for Operations

People Involved in

ITS Architectures

chapter 1 introduction
Applying a Regional ITS Architecture to Support Planning for Operations 5

2 Planning for Operations and Architecture –

A Quick Tutorial

2.1.	 Operations and ITS – A Unified View

Before delving into the opportunities to leverage the 

regional ITS architecture to enhance planning for 

operations, it is important to clarify what is meant by 

“ITS” and “operations.” The relationship between ITS 

and operations is often defined in this way: ITS is the 

enabling technology for operations. ITS and 

operations both aim to address one or more of the major 

multimodal transportation system goal areas: efficiency, 

safety, reliability, security, and environmental quality. It 

should be acknowledged that the use of the terms “ITS” 

and “operations” can differ somewhat across 

communities and the relationship between the two has 

evolved over time. The term “operations” is used 

synonymously in this primer with “management and 

operations” and “M&O.” 

Management and operations (or operations) is defined as:

“A regionally integrated program to optimize the performance of existing infrastructure 

through the implementation of multimodal and intermodal, cross-jurisdictional 

systems, services, and projects designed to preserve capacity and improved security, 

safety, and reliability of the regional transportation system; includes regional 

operations collaboration and coordination activities between transportation and public 

safety agencies.” 1

The term includes traffic detection and surveillance, arterial management, freeway 

management, transit operations, demand management, electronic toll collection, and 

many other strategies.

Intelligent transportation systems is defined as:

“Intelligent Transportation Systems represent the application of information 

processing, communications technologies, advanced control strategies, and 

electronics to the field of transportation.” 2

Despite the fairly narrow, technology-focused definition, the ITS program has 

historically looked beyond technology and addressed all aspects of intelligent 

transportation systems including their development (e.g., the systems engineering 

process), operation, and evaluation. The regional ITS architecture in particular takes a 

1 United States Code Title 23, Section 101(a) as amended by SAFETEA-LU Technical Corrections Act of 2008. 2 United States Code Title 23 CFR 940: Intelligent Transportation System Architecture and Standards.

Operations is what you do.

ITS is the technology.

Figure 4: ITS Technology Supports Operations.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
6

broader, systems perspective of ITS that includes other elements of a “system” 

involved in providing a transportation service, including the roles and responsibilities 

of operators, institutional coordination and agreements, and the flows of information 

between system elements. In fact, the regional ITS architecture is designed to be 

technology-independent, further blurring the distinction between “operations” and 

“ITS.” This broader view of ITS overlaps with operations, which makes the regional 

ITS architecture a significant tool for supporting operations in the metropolitan/

statewide transportation planning process.

For the purposes of this primer, the terms ITS and operations will be used as defined 

above. ITS will be viewed as the systems involving electronics, communications, or 

information processing used to support management and operations. 

2.2. What is Planning for Operations?

The transportation planning process includes development of a regional vision and 

goals, identification of alternate improvement strategies, evaluation and prioritization 

of strategies, development of the transportation plan and transportation improvement 

programs, project development, and systems operations.3 It is a continuing, 

collaborative, and comprehensive process that includes the consideration of several 

critical factors: economic development, air quality, budgets, and others. 

Planning for operations is a joint effort between planners and operators to support 

improved regional transportation systems management and operations. It requires 

coordination and collaboration between a number of regional partners, including 

planning staff and operations staff from metropolitan planning organizations (MPOs), 

State departments of transportation, transit agencies, highway agencies, toll 

authorities, and local governments. It involves the consideration of management and 

operations (M&O) strategies in transportation planning – including the integration of 

M&O strategies in metropolitan and statewide transportation plans. 

The Federal Highway Administration (FHWA) and the Federal Transit Administration 

(FTA) recommend the use of an objectives-driven, performance-based approach to 

planning for operations as an effective way to integrate operations in the metropolitan 

and statewide transportation planning processes. An important U.S. DOT resource to 

consult for learning more about the approach is, Advancing Metropolitan Planning for 

Operations: An Objectives-Driven, Performance-Based Approach - A Guidebook.

4

 

This approach helps regions meet Federal transportation planning requirements for 

including “operational and management strategies to improve the performance of 

existing transportation facilities” in the metropolitan transportation plan (MTP)5 and 

promoting “efficient system management and operation.”6

3 U.S. Department of Transportation, Federal Highway Administration and Federal Transit Administration, The Transportation 

Planning Capacity Building Program, The Transportation Planning Process: Key Issues A Briefing Book for Transportation 

Decisionmakers, Officials, and Staff, Publication No. FHWA-HEP-07-039,

http://www.planning.dot.gov/documents/BriefingBook/BBook.htm. 4 U.S. Department of Transportation, Federal Highway Administration and Federal Transit Administration, Advancing Metropolitan 

Planning for Operations: An Objectives-Driven, Performance-Based Approach - A Guidebook, Publication No.

FHWA-HOP-10-026, http://www.plan4operations.dot.gov/. 5 Other common terms used for the “metropolitan transportation plan” are long-range transportation plan and regional 

transportation plan. 6 “Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU),” Section 6001(i), 2005.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 7

The recommended approach focuses on working toward desired system performance 

outcomes for transportation system users, such as increased travel time reliability, 

rather than just responding to problems. It acknowledges the widely-accepted 

principle that what is measured matters in decisionmaking, and setting specific, 

measurable performance objectives will facilitate incorporating operations strategies 

into the metropolitan and statewide transportation plans as well as agencies’ operating 

budgets. Operations strategies take a variety of forms including programs or projects 

focused on managing and operating the transportation network, projects to deploy ITS 

infrastructure, programs that fund operating and maintaining new and existing ITS 

infrastructure, and operations elements of major capital projects. 

Developing operations objectives that state what a region plans to achieve regarding 

the operational performance of the transportation system is the center of this 

approach to planning for operations. Operations objectives are included in the region’s 

transportation plan and provide strategic direction for including operations programs 

and projects in the plan and statewide and metropolitan transportation improvement 

programs (STIP/TIP). These objectives provide specific, measurable, agreed-upon 

statements of system performance that can be tracked on the regional level and 

inform investment decisions. The approach provides a direct connection between 

operations objectives and investment decisions. Operations objectives may address 

concerns such as recurring and non-recurring congestion, access to traveler 

information, emergency response time, incident management coordination, and transit 

operations, among others. Regions create operations objectives that are tailored for 

their size, resource availability, political commitment for operations, and performance 

monitoring capabilities.

The following list gives the primary elements of the objectives-driven, performancebased approach to planning for operations.7

■ Regional Goals. Establish one or more goals that focus on efficiently managing 

and operating the transportation system.

■ Operations Objectives. Develop operations objectives— specific, measurable 

statements of performance— to include in the metropolitan or long-range statewide 

transportation plan (MTP/LRSTP) that will lead to accomplishing the goal or goals.

■ Performance Measures. Using a systematic approach, develop performance 

measures, analyze transportation performance issues, and recommend M&O 

strategies.

■ M&O Strategies. Select M&O strategies within fiscal constraints to meet 

operations objectives for inclusion in the MTP/LRSTP and STIP/TIP.

■ Investment and Implementation. Implement strategies, including program 

investments, collaborative activities, and projects.

■ Monitoring and Evaluation. Monitor and evaluate the effectiveness of 

implemented strategies and track progress toward meeting operations objectives.

7 U.S. Department of Transportation, Federal Highway Administration and Federal Transit Administration, Advancing Metropolitan 

Planning for Operations: The Building Blocks of a Model Transportation Plan Incorporating Operations – A Desk Reference, 

Publication No. FHWA-HOP-10-027, http://www.ops.fhwa.dot.gov/publications/fhwahop10027/index.htm.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
8

The approach (shown in Figure 5) is 

iterative, with monitoring and 

evaluating used to refine and adjust 

operations objectives over time. 

Coordinating and collaborating 

among planners and operators is a 

critical component of the approach, 

which supports developing agreedupon regional operations objectives, 

identifying strategies, and 

monitoring and evaluating system 

performance. 

Figure 5 illustrates the approach to 

planning for operations guided by 

operations objectives and founded 

on performance measures and data. 

The figure shows the basic elements 

of the transportation planning 

process with a focus on 

management and operations. 

When applied, the objectives-driven, performance-based approach to planning for 

operations is frequently integrated into the transportation planning process such that 

management and operations is combined with other types of regional needs and 

solutions such as safety, environment, accessibility, and security in the development 

of objectives and the systematic process to develop and select strategies for the plan 

and improvement program. 

The congestion management process (CMP), as outlined in SAFETEA-LU, uses an 

objectives-driven, performance-based approach to address congestion in a region.8

 

The CMP is a federally-required process for MPOs in areas with populations over 

200,000. The CMP is used to identify congestion and its causes, propose mitigation 

strategies, and evaluate the effectiveness of implemented strategies. It is an integral 

part of the planning process that influences decisionmaking and feeds projects and 

strategies directly into the plan and TIP. In some metropolitan regions, this may be the 

primary use of the objectives-driven, performance-based approach to integrating 

operations into the metropolitan planning process. 

In summary, a plan resulting from the objectives-driven, performance-based approach 

for operations should include the following: 

■ Goals and measurable objectives that advance operational performance outcomes 

for the regional transportation system; 

■ Performance measures that allow the region to track progress toward achieving its 

objectives; and 

■ Clearly defined M&O strategies backed by specific performance measures that 

allow for evaluation. 

8 See Appendix B

Define Performance Measures

Determine Operations Needs

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Monitoring and Evaluation

Regional Goals and Motivation

Operations Objectives

Implementation/System Operations

M&O Strategies

Systematic Process to Develop and

Select M&O Strategies to Meet Objectives

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Metropolitan or Statewide 

Transportation Plan

Figure 5: An Objectives-Driven, Performance-Based Approach to Planning for Operations.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 9

A “regional ITS 

architecture” is defined as 

“A specific, tailored 

framework for ensuring 

institutional agreement and 

technical integration for the 

implementation of ITS 

projects or groups of 

projects in a particular 

region. It functionally 

defines what pieces of the 

system are linked to others 

and what information is 

exchanged between 

them."9

9 U.S. Department of Transportation, FHWA, Regional ITS Architecture Guidance Document, FHWA-HOP-06-112, 2006. Available at:

http://www.ops.fhwa.dot.gov/publications/regitsarchguide/index.htm, last accessed August 25, 2011.

2.3. What is a Regional ITS Architecture?

Ongoing rapid advances in information processing and communications technology 

create new opportunities for transportation professionals to deliver more efficient and 

effective transportation services. Many of these opportunities are predicated upon 

effective coordination between organizations— at both an institutional and technical 

level. To encourage and enable this coordination, the U.S. DOT has developed a set 

of tools that support development and use of a “regional ITS architecture” that is 

intended to help identify and exploit these opportunities for cost-effective cooperation. 

A regional ITS architecture is intended to be a cornerstone of planning for effective 

inter-agency integration and for deployment and operation of technology-based 

projects. 

Complementing planning for operations, a regional ITS architecture supports planning 

for integration. On the next page, Figure 6 shows a notional view that includes many of 

the key components of a regional ITS architecture.

As shown, most of the regional ITS architecture is devoted to showing all of the 

existing and planned operational transportation systems in a region and how they will 

fit together. From a planning perspective, the regional ITS architecture should support 

the region’s objectives and also support the specific needs of transportation planning 

agencies. It should show how data is collected, archived, and processed to support 

transportation planning and performance monitoring.

The regional ITS architecture consists of a number of components, including quite a few 

that are useful in transportation planning and referenced in later chapters of this primer. 

Each of the components answers one or more key questions about the integrated 

transportation system that is planned for the region. Let’s take a minute to introduce you 

to the key components of a regional ITS architecture. For the most benefit, locate and 

open your regional ITS architecture (most regional ITS architectures are available on-line) 

and look at how it covers each of the following regional ITS architecture components.

Additional Transportation Planning for Operations Resources

U.S. Department of Transportation, FHWA, Advancing Metropolitan Planning for Operations: An Objectives-Driven, 

Performance-Based Approach – A Guidebook, FHWA-HOP-10-026, 2010. 

Available at: http://www.ops.fhwa.dot.gov/publications/fhwahop10026/index.htm, last accessed August 29, 2011.

U.S. Department of Transportation, FHWA, Advancing Metropolitan Planning for Operations: The Building Blocks of a Model 

Transportation Plan Incorporating Operations – A Desk Reference, FHWA-HOP-10-027, 2010. Available at:

http://www.ops.fhwa.dot.gov/publications/fhwahop10027/index.htm, last accessed August 29, 2011.

U.S. Department of Transportation, FHWA, Congestion Management Process: A Guidebook, FHWA-HEP-11-011, 2011. Available 

at: http://www.fhwa.dot.gov/planning/congestion_management_process/cmp_guidebook/, last accessed August 29, 2011.

U.S. Department of Transportation, FHWA, Statewide Opportunities for Integrating Operations, Safety and Multimodal 

Planning: A Reference Manual, FHWA-HOP-10-028, 2010. Available at:

http://www.fhwa.dot.gov/planning/statewide/manual/index.cfm, last accessed August 29, 2011.

U.S. Department of Transportation, FHWA, Regional Concept for Transportation Operations: The Blueprint for Action – A Primer, 

FHWA-HOP-07-122, 2007. Available at: http://www.ops.fhwa.dot.gov/publications/rctoprimer/index.htm, last August 29, 2011.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
10

Scope: The regional ITS architecture definition begins with 

a clear statement of the geographic and jurisdictional 

boundaries, the time horizon, and the scope of 

transportation services that are covered by the architecture. 

The Rule/Policy leaves a lot of latitude to the region in 

defining the scope, but suggests that the regional ITS 

architecture cover the entire metropolitan area at a minimum. Transportation planners 

should make sure the scope is as consistent as possible with the scope of the regional 

transportation planning activities to facilitate use in planning for operations.

Stakeholders: A list of the traffic agencies, transit 

operators, public safety agencies, traveler 

information providers and other organizations and 

groups that plan, develop, operate, maintain, and 

use the regional transportation system is included 

in every regional ITS architecture. This broad 

stakeholder list should include all of the agencies that are involved in transportation 

planning, operations, and management as well as groups that use the transportation 

system (e.g., fleet operators) or impact its operation (e.g., special event venue owner/

operators). A typical stakeholder list might include 50 agencies and other 

organizations by name, accompanied by a short description.

Roles and Responsibilities: The regional ITS architecture does more than list the 

stakeholders; it defines the high-level roles and responsibilities of each of the 

stakeholders that operate and manage the transportation system as part of an 

“operational concept” for the region. The roles and responsibilities are short statements 

like “Share CCTV video feeds with other agencies in the region” and “Share Fire CAD 

feeds with DOT.”

In 1997, Congress passed 

the Transportation Equity 

Act for the 21st Century 

(TEA-21) to address the 

need to begin to work toward 

regionally integrated 

transportation systems. In 

January 2001, FHWA 

published Rule 940 (ITS 

Architecture and Standards) 

and FTA published a 

companion policy to 

implement Section 5206(e) 

of TEA-21. This Rule/Policy 

seeks to foster regional 

integration by requiring that 

all ITS projects funded from 

the Highway Trust Fund be 

in conformance with the 

National ITS Architecture 

and officially adopted 

standards. “Conformance 

with the National ITS 

Architecture” is defined in 

the final Rule/Policy as using 

the National ITS Architecture 

to develop a “regional ITS 

architecture” that would be 

tailored to address the local 

situation and ITS investment 

needs, and the subsequent 

adherence of ITS projects to 

the regional ITS 

architecture. This Rule/

Policy continues under the 

current Federal 

transportation act.

Traffic

Planning

Scope

Traveler

Information

Traffic

Archive Data

Traveler

Archive Data

Emergency

Archive Data

Transit

Archive Data

Transit Public Safety

Figure 6: A High-Level ITS Architecture.

Scope

• Geographic

• Timeframe

• Services

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 11

Inventory: This is a list of the existing and planned components or “elements” of the 

regional transportation system. The inventory elements are frequently systems in their 

own right and include the operational centers (e.g., a State DOT Freeway 

Management Center), field equipment (e.g., the dynamic message signs, closedcircuit television (CCTV) cameras, and signal systems), vehicles (e.g., transit vehicles 

and public safety vehicles), and traveler equipment (i.e., the devices the traveler uses). 

Importantly for planning, the inventory should also include any monitoring and data 

collection systems that are used by transportation planners. The objective in defining 

the inventory is to include enough detail to identify the key integration points— the 

endpoints for the inter-agency interfaces and other interfaces that are prime 

candidates for standardization.

Interfaces: A definition of the interfaces between 

the inventory elements is a focal point of the 

regional ITS architecture. Each interface is 

represented as both an “Interconnect” (Is there a 

connection between the two elements?) and as a 

set of information flows or “architecture flows” that 

describe the information that is shared. The 

architecture flows are also associated with 

relevant ITS standards.

Services: The National ITS Architecture provides a menu of approximately 

100 “Service Packages”10 or ITS strategies that may be included in the 

regional ITS architecture. The list of services is comprehensive, covering all 

modes and all types of roads and reflecting the full breadth of ITS services 

that have been implemented to date (and a few that have yet to be 

implemented in an operational setting). ITS services are grouped into 

bundles. For example, the Archived Data (AD) bundle includes an “ITS 

Data Warehouse” service. Each ITS service is linked specifically to the ITS 

inventory elements and interfaces that are included in that service, 

effectively partitioning the regional ITS architecture based on the services 

that are provided. The ITS services that are included in the regional ITS 

architecture represent a consensus of the architecture stakeholders. The 

ITS services are linked to costs, benefits, and lessons learned, which can 

aid in evaluating the services that are most attractive for implementation in 

your region.11

Project Sequencing: The regional ITS architecture is implemented 

through many transportation programs and projects that occur over years 

or even decades. The regional ITS architecture includes a sequence that 

allocates projects to broad timeframes like near- (0-3 years), mid- (3-7 

years), and long-term (8+ years). The project sequencing often provides 

finer granularity than the ITS services, particularly for near-term projects.

10 The term “Market Package” is being replaced by “Service Package” in the upcoming release of the National ITS Architecture. 

We use “Service Package” here and throughout the primer to be consistent with the new terminology. 11 The links to costs, benefits and lessons learned will be included in Version 7.0 of the National ITS Architecture expected in early 

2012.

City TOC Planning

Archive requests

Traffic archive data

Figure 7: Example of Interfaces between 

Elements.

AD2: ITS Data 

Warehouse

Planning

Traffic

Archive Data

Traveler

Archive Data

Emergency

Archive Data

Transit

Archive Data

Figure 8: Illustration of a Service Package.

Planning

Traffic

Archive Data

Near Term Projects:

A: Traffic Data Archive

Mid Term Projects:

B: Extend Archive for 

Transit

C: Archive Traffic 

Incident Performance

Emergency

Archive Data

Transit

Archive Data

A

B C

Figure 9: Illustration of Project Sequencing.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
12

Agreements: The regional ITS architecture also includes a list of agreements, though 

it may not be fully populated in your regional ITS architecture. The idea is that 

institutional coordination is required to support the technical integration that is shown 

in the architecture. The list of agreements should identify the existing and planned 

agreements in the region that are needed to support an integrated transportation 

system. Note that the agreements should extend beyond implementation into 

operational agreements that define agency roles and responsibilities for system 

operation

Those are the regional ITS architecture components that are most central to planning 

for operations. Several other components of the regional ITS architecture are primarily 

oriented towards project development including functional requirements and 

identification of ITS standards. All of the architecture components are defined in more 

detail in the Regional ITS Architecture Guidance Document.12

The Regional ITS Architecture Development Process

A regional ITS architecture is developed using the process shown in 

Figure 10. This process is defined in detail in the Regional ITS 

Architecture Guidance Document. A brief overview of the process will 

suffice for most readers of this primer. The key steps are summarized 

here.

Get Started: The regional ITS architecture effort begins with a focus on 

the institutions and people involved. Based on the scope of the region, 

the relevant stakeholders and one or more champions are identified, the 

team that will be involved in architecture development is organized, and 

the overall development effort is planned. 

Gather Data: Once the stakeholders are involved and a plan is in place 

for assembling their input into a consensus regional ITS architecture, the 

focus shifts to the ITS systems in the region. In this step the existing and 

planned ITS systems in the region are inventoried; the roles and 

responsibilities of each stakeholder in developing, operating, and 

maintaining these ITS systems are defined; the ITS services that should 

be provided in the region are identified; and the contribution (in 

terms of functionality) that each system will make to provide 

these ITS services is documented.

Define Interfaces: Once the ITS systems in the region are 

identified and functionally defined, the existing and planned 

interfaces between these systems are defined. First, the connections (or 

“Interconnects”) between systems are identified, and then the information that will be 

exchanged on each of the connections is defined.

Implementation: Once the system interfaces are delineated, additional products can 

be defined that will guide implementation of the projects that will flow from the regional 

ITS architecture. These include a sequence of projects, a list of needed agency 

agreements, and a list of standards that can be considered for project implementation.

12 U.S. Department of Transportation, FHWA, Regional ITS Architecture Guidance Document, FHWA-HOP-06-112. Available at: 

http://www.ops.fhwa.dot.gov/publications/regitsarchguide/index.htm, last accessed August 25, 2011. Iterative Process

Step #6: 

Maintain the Architecture

Step #5: 

Use the Architecture

Need│Scope│Champions│Stakeholders

Step #1: Get Started 

Inventory│Needs and Services│

Operational Concept│

Functional Requirements

Step #2: Gather Data

Interconnects│Information Flows

Step #3: Define Interfaces

Project Sequencing│ITS Standards│

List of Agency Agreements

Step #4: Implementation

Figure 10: Regional ITS Architecture Development Process.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 13

Use the Regional ITS Architecture: The real success of the regional ITS 

architecture effort hinges on effective use of the architecture once it is developed. The 

regional ITS architecture is an important tool for use in transportation planning, 

programming, and project implementation. It can identify opportunities for making ITS 

investments in a more cost-effective fashion. This step is where the benefits are 

realized. This step is the focus of this primer.

Maintain the Regional ITS Architecture: The regional ITS architecture must be 

updated as ITS projects are implemented, new ITS priorities and strategies emerge 

through the transportation planning process, and the scope of ITS continues to evolve. 

A maintenance plan is used to guide controlled updates to the regional ITS 

architecture baseline so that it continues to accurately reflect the region’s existing ITS 

capabilities and future plans. Chapter 4 includes ideas for enhancing your architecture 

so that it better supports planning for operations in your next architecture update.

2.4. Making the Connections

After reviewing the objectives-driven, performance-based approach for planning for 

operations in Section 2.2 and the development of the regional ITS architecture in 

Section 2.3, it is easy to see similarities between the two processes and get a sense 

that there is potential in leveraging a closer connection. This section looks at the 

potential connections between the two processes. 

The objectives-driven, performance based approach for planning for operations and the 

regional ITS architecture process have complementary strengths. The architecture 

development process begins with an understanding of regional needs and the current 

state of the transportation system based on input from a broad coalition of stakeholders. 

It results in a planning framework (the regional ITS architecture) and a sequence of 

integrated projects that implement a portion of that framework. The strength of the 

regional ITS architecture process is its development of an integrated view of the regional 

transportation system based on a set of identified services or strategies. This 

complements the planning for operations approach, where the focus is on defining the 

most effective strategies for a region based on high-level goals and operational 

objectives. By connecting the two processes, you combine the strong basis for selecting 

strategies in planning for operations with the strength of the architecture development 

process in defining an integrated framework based on selected services. 

Additional Regional ITS Architecture Resources

U.S. Department of Transportation, RITA, U.S. National ITS Architecture Web Site. Available at http://www.its.dot.gov/arch, last 

accessed August 25, 2011.

U.S. Department of Transportation, RITA, Turbo Architecture Web Site. Available at:

http://www.iteris.com/itsarch/html/turbo/turbomain.htm, last accessed August 25, 2011.

U.S. Department of Transportation, FHWA, Regional ITS Architecture Guidance Document, FHWA-HOP-06-112, 2006. 

Available at: http://www.ops.fhwa.dot.gov/publications/regitsarchguide/index.htm, last accessed August 25, 2011.

U.S. Department of Transportation, FHWA, Systems Engineering for ITS Handbook, FHWA-HOP-07-069, 2007. Available at: 

http://ops.fhwa.dot.gov/publications/seitsguide/index.htm, last accessed August 25, 2011.

U.S. Department of Transportation, FHWA, Systems Engineering Guidebook for ITS Web Site. Available at:

http://www.fhwa.dot.gov/cadiv/segb/, last accessed August 25, 2011.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
14

Linking the regional ITS architecture and the process for integrating operations into 

transportation planning (i.e., “planning for operations”) depends on factors such as the 

format of planning for operations in the region, the accuracy and thoroughness of the 

regional ITS architecture, and when the updates of the plan and architecture occur. The 

next several pages show three alternative scenarios for connecting the architecture and planning for operations based on the relative timings of the updates.

The benefits and challenges associated with each scenario are listed in Section 4.4.

Scenario A: Regional ITS Architecture Updated Prior to the Metropolitan/

Statewide Transportation Plan Update 

In this scenario, an existing regional ITS architecture is used to support planning for 

operations as part of a metropolitan or statewide transportation plan update. The 

architecture is used as a resource that can provide useful input to incorporating 

operations into the planning and programming processes. This regional ITS 

architecture will not undergo a major update as part of this scenario.

Figure 11 shows seven opportunities for the regional ITS architecture to provide input 

to the objectives-driven, performance-based approach to planning for operations. 

Each numbered opportunity corresponds with a connection in the figure.

1. Leverage any existing collaborative ITS groups to 

assist with the integration of operations into the 

metropolitan or statewide transportation planning 

process.

2. Examine elements of ITS in the architecture such as 

the ITS needs and services to gain information on 

the operations issues and envisioned operational 

services for the development of operations 

objectives.

3. Identify data available to support performance 

measures for tracking objectives and monitoring 

system performance.

4. Obtain information on operations needs by looking 

for gaps in regional functionality of ITS services and 

stated operations needs. Examine the needs 

associated with operating and maintaining the ITS 

infrastructure already in place. 

5. Gather ideas for potential M&O strategies by 

examining the ITS services or service packages 

selected for the architecture.

6. Examine the ITS inventory elements associated with 

ITS services/service packages that relate to M&O 

strategies in the plan to help define projects and 

programs that include both implementation and 

ongoing operations and maintenance of ITS. Use 

the list of projects in the ITS architecture to also 

provide input to project definition for the STIP/TIP. 

Select ITS-related activities to be funded that are 

consistent with the ITS architecture.

7. Mine information flows, ITS standards, and other 

information from the architecture to support project 

development and implementation. 

Figure 11: Diagram Depicting Scenario A: Regional ITS Architecture Updated Prior to 

the Metropolitan/Statewide Transportation Plan Update.

Regional Collaboration and Coordination

Regional 

ITS Architecture

Metropolitan or Statewide 

Transportation Plan

Implementation/System Operations

Define Performance Measures

Determine Operations Needs

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Operations Objectives

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Regional Goals and Motivation

Monitoring and Evaluation

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

1

2

3

4

5

6

7

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 15

Figure 12 provides an example of how the regional ITS architecture could be used to 

provide valuable input to the development of operations objectives and the 

identification of data sources and partners for tracking performance measures. The 

illustration also shows how the architecture could be used to identify M&O strategies 

for achieving an operations objective centered on arterial delay. The fact sheet used 

in the example is from a recent FHWA and FTA publication containing nearly 100 

fact sheets highlighting operations objectives and performance measures across a 

spectrum of operations areas.13

13 U.S. Department of Transportation, FHWA, Advancing Metropolitan Planning for Operations: The Building Blocks of 

a Model Transportation Plan Incorporating Operations – A Desk Reference, FHWA-HOP-10-027, 2010. Available at: 

http://www.ops.fhwa.dot.gov/publications/fhwahop10027/index.htm, last accessed August 29, 2011.

General Description

These objectives seek to address delay experienced on arterials. Arterial roads primarily serve through traffic and provide 

access to abutting properties as a secondary function. 

Arterial Management: Delay 3.3.4

Advancing Metropolitan Planning for Operations | 15

Operations 

Objectives

•	 Decrease the seconds of control delay per vehicle on arterial roads by X percent in Y 

years. (Control delay is defined as the portion of the total delay attributed to traffic signal 

operation for signalized intersections).

•	 Increase the miles of arterials in the region operating at level of service (LOS) Z by X 

percent in Y years.

Performance 

Measures

•	 Control delay seconds per vehicle.

•	 Percent of arterial miles in region operating at LOS Z.

Anticipated Data 

Needs

•	 Travel times on arterials near traffic signals.

•	 Speed, volume/capacity or other measures of level of service.

Data Resources 

and Partners

•	 Partner agencies that operate and maintain arterials in the region.

M&O Strategies 

to Consider

M&O strategies designed to address the management of traffic on arterial roads typically include a blend 

of outreach, guidance, training, and research to advance four major types of strategies: traffic signal 

improvements, advanced traffic signal control, traffic monitoring, and access management.

Safety-related 

Impacts

Select examples of associated M&O strategies and their safety impacts include:

•	 Modify access point density: The safety impact of reducing the number of access points is the

potential reduction in injury and non-injury crash frequency, as well as angle and sideswipe

collisions at intersections and mid-block areas. Source: HSM, First Edition.

•	 Remove unwarranted signals: The safety impact of this treatment is the potential for

decreasing the frequency of collisions. Targets for this action are signalized intersections

where traffic volumes and safety records do not warrant a traffic signal. This action also

includes the potential to eliminate excessive delay and disobedience to traffic signals and

decreases the use of inappropriate routes to avoid signals. Right angle crashes may increase

after signal removal. Source: NCHRP 500 Volume 12 (effectiveness categorized as”proven”).

•	 Provide a right-turn lane: The crash modification factor (crash modification factor) for this

treatment for all crashes at stop-controlled intersections is a 0.86 with a standard error

of 0.06. Therefore the range of the crash modification factor is 0.98 to 0.74. Relating to all

crashes at signalized intersections, the crash modification factor for this treatment is 0.96

with a standard error of 0.02. Therefore the range of the crash modification factor is 1.00 to

0.92.

Note: The existing number of crashes is multiplied by the crash modification factor to

determine the number of crashes following implementation of a treatment.

Figure 12: Hypothetical Example of Where the Regional ITS Architecture Assists Planning in Specific Operations Areas. Fact Sheets

Operations needs documented 

during regional ITS architecture 

development helped focus 

operations objective on arterial 

delay. In this example, 

improving arterial travel times 

were identified as a need.

Architecture identifies data that 

will be collected by six municipal 

signal systems and archived by 

a planned data warehouse 

operated by the State DOT. 

Review suggests that probe 

surveillance should be added to 

the architecture to support 

collection of travel times and 

delay.

Architecture inventory used to 

identify all municipal signal 

systems as well as signals 

operated by the State DOT.

ITS service packages related to 

arterial management helped 

identify M&O strategies to 

reduce delay on arterials. 

Identified:

• ATMS01: Network 

Surveillance

• ATMS02: Traffic Probe 

Surveillance

• ATMS03: Traffic Signal 

Control

• ATMS07: Regional Traffic 

Control

Verified that all six 

municipalities included in 

ATMS03 and identified a gap to 

address: two partner agencies 

were not included in the 

Regional Traffic Control system.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
16

Scenario B: Regional ITS Architecture Updated After the Metropolitan/

Statewide Transportation Plan Update 

When the regional ITS architecture is updated following the development of the 

metropolitan or statewide transportation plan, the architecture supports planning for 

operations by responding to the strategic direction set by the goals, objectives, and 

M&O strategies incorporated into the plan. The architecture is used to “drill down” into 

how the M&O strategies, programs, or projects can be regionally integrated into the 

transportation system and what ITS may be needed for implementation. This is 

illustrated in Figure 13 below. As above, each numbered opportunity listed 

corresponds with numbered connections in the figure.

1. Leverage any regional operations planning groups to support the ITS architecture 

update.

2. Identify goals and operations objectives from the transportation plan to direct the 

decisions made in the architecture update.

3. Adopt and update the system performance needs defined for the region during the 

development of the plan.

4. Select service packages or services that correspond to M&O strategies selected for 

the plan.

5. Incorporate archived data services and appropriate flows in the architecture to 

support performance measures selected to track operations objectives and system 

performance. 

6. Update the ITS inventory, interconnects, and information flows to account for any 

newly planned M&O/ITS programs and projects.

Iterative Process

Step #6: 

Maintain the Architecture

Step #5: 

Use the Architecture

Need│Scope│Champions│Stakeholders

Step #1: Get Started 

Inventory│Needs and Services│

Operational Concept│

Functional Requirements

Step #2: Gather Data

Interconnects│Information Flows

Step #3: Define Interfaces

Project Sequencing│ITS Standards│

List of Agency Agreements

Step #4: Implementation

Regional Collaboration/Coordination

2

3

4

5

6

Metropolitan or Statewide 

Transportation Plan

1

Goals/Objectives

M&O Strategies

Perf Measures

Projects

Needs

Metropolitan or Statewide 

Transportation Improvement 

Program or Other Funding Programs

Implementation/System Operations

Figure 13: Diagram Depicting Scenario B: Regional ITS Architecture Updated After the Metropolitan/Statewide Transportation Plan Update. 

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 17

Scenario C: Regional ITS Architecture Updated at the Same Time as the 

Metropolitan/Statewide Transportation Plan Update 

A regional ITS architecture updated in conjunction with the transportation plan for the 

metropolitan area or State opens up the greatest opportunities for leveraging the 

synergies between the processes. There are opportunities to combine or closely 

associate steps in the planning for operations and ITS architecture update processes 

to eliminate duplicative efforts. 

Figure 14 highlights five important connections that can be leveraged between the two 

processes for a more effective, coordinated transportation system. As an overview, 

these five primary areas of linkage are 1) regional collaboration and coordination 

across processes, 2) operations objectives and the overarching “gather data” step, 3) 

operations and system performance needs, 4) M&O strategies and ITS services, and 

5) defining and implementing operations programs and projects in a regionally 

integrated context.

Approach to Planning for Operations

Inventory Systems

Determine Needs

Determine Services

Develop Operational Concept

Define Functional Requirements

Step #2: Gather Data

1 Regional Collaboration and Coordination

2

3

Metropolitan or Statewide 

Transportation Plan

Operations Objectives

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Regional Goals and Motivation

Implementation/System Operations

Monitoring and Evaluation

Define Performance Measures

Determine Operations Needs

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Regional ITS Architecture 

Development for Use

Need│Scope│Champions│Stakeholders

Step #1: Get Started 

Interconnects│Information Flows

Step #3: Define Interfaces

Project Sequencing│ITS Standards│

List of Agency Agreements

Step #4: Implementation

Iterative Process

Step #6: 

Maintain the Architecture

Step #5: 

Use the Architecture

4

5

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Figure 14: Diagram Depicting Scenario C: Regional ITS Architecture Updated at the Same Time as the Metropolitan/Statewide Transportation Plan Update.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
18

1. Regional collaboration and coordination.

The processes are conducted by overlapping groups of transportation operations 

and ITS stakeholders including staff from planning agencies, State and local road 

operating agencies, transit agencies, public safety, and others. In many cases, the 

same regional committee that supports the regional ITS architecture can also 

support planning for operations, leveraging the overlaps and opportunity for 

synergy between the two activities. The composition of the staff may shift from 

management to technical as the work moves from strategic to implementation. In 

many regions, though, the same individuals at an agency focus on integrating 

operations into the planning process and developing the regional ITS architecture. 

Leveraging the same agencies, if not the same individuals, for both processes 

yields benefits in terms of knowledge transfer and outreach requirements.

2. Operations objectives and gather data.

In the second step of the regional ITS architecture development, gather data, 

several significant activities occur that should both influence and be influenced by 

the development of operations objectives. It is critically important for connecting 

the two processes that the operations objectives guide the identification of needs 

and services in the architecture. This will be discussed in several places in the 

primer. The systems inventory conducted early in the architecture development can 

provide useful information on the available sources of operations data that could be 

used to track measurable objectives. Data availability is a significant factor in 

establishing specific objectives. In addition, the operations expertise of the 

stakeholders brought together for the regional ITS architecture should be leveraged 

in setting the direction for operations in the region.

3. Operations and system performance needs.

The regional ITS architecture update calls for the stakeholders to “determine needs 

and services.” This task is fundamentally a planning task that should be 

coordinated with the overall transportation planning process. When the plan and 

architecture are updated at the same time, these parallel activities can be 

combined for a more coherent and efficient process. When combined, the 

operations needs of the transportation system can be identified once based on the 

regional operations objectives and overall goals and used in both the update of the 

architecture and planning for operations to drive the identification of operations 

solutions. 

chapter 2 Planning for Operations and Architecture – A Quick Tutorial
Applying a Regional ITS Architecture to Support Planning for Operations 19

4. M&O strategies and ITS services.

Identifying M&O strategies to include in the metropolitan or statewide 

transportation plan is parallel to the “Determine Services” task of the ITS 

architecture update. Many aspects of these two processes can and should be 

combined for the sake of efficiency and consistency. The ITS services identified for 

a regional ITS architecture are selected from a comprehensive menu of “service 

packages” and there is considerable overlap between service packages and M&O 

strategies. The exceptions include those M&O strategies that are not based on ITS 

and the ITS services for improved safety, environment, and others without an 

operations focus. 

M&O strategies are evaluated and selected for inclusion in the transportation plan, 

at least at the metropolitan planning level. To enhance coordination with the overall 

planning process, the regional ITS architecture may include those services that are 

planned or currently existing. Where there are differences, the regional ITS 

architecture could indicate which services are explicitly included in a plan.

5.	 Defining and implementing operations programs and projects in a

regionally integrated context.

The operational concept, functional requirements, and interfaces that are defined 

in the regional ITS architecture can be used to improve understanding of the 

integration needs and dependencies between projects. The detailed definition of 

each project in the regional ITS architecture helps to identify the scope of an 

operations project or program and the roles and responsibilities for implementing 

ITS as well as operating and maintaining it over the long-term.

Developing a schedule for program and project funding as part of the STIP or TIP 

development can also be performed in conjunction with project sequencing in the 

regional ITS architecture. The list of projects arising from the regional ITS 

architecture should be consistent with the sequence of projects and programs in 

the STIP/TIP. 

During project development and implementation, the interconnects, information 

flows, list of agency agreements, and ITS standards of the regional ITS architecture 

should be mined for input.

chapter 2 Planning for Operations and Architecture – A Quick Tutorial

Applying a Regional ITS Architecture to Support Planning for Operations 21

3 Opportunities for Architecture Use

Effectively integrating management and operations (M&O) into the metropolitan and 

statewide transportation planning processes requires significant inter-agency 

collaboration and a regional view of the area’s multimodal transportation system. 

Because many M&O strategies are underpinned by ITS, the coordination of planning 

for ITS among agencies at the institutional and technical level is an essential element 

to planning for operations. The regional ITS architecture, with a focus on integrating 

transportation services supported by ITS, presents a significant opportunity to support 

the needs for effective planning for operations. The shift in planning for operations to 

an objectives-driven, performance-based approach increases the value that could be 

leveraged from the regional ITS architecture given the architecture’s emphasis on 

information flows. 

This section identifies several opportunities among many regions in the United States 

to get more value from their regional ITS architectures through a greater connection to 

operations planning. The regional ITS architecture can strengthen the objectivesdriven, performance-based approach to planning for operations in a region. By not 

taking advantage of the opportunities to connect the regional ITS architecture to 

planning for operations, regions risk duplicated effort, decreased planning efficiency, 

and fragmented operations services. 

Each of the following sections highlights a step in the objectives-driven, performancebased approach and identifies ways in which a regional ITS architecture can support 

that step. It is important to note that “architecture use” is a two-way street— the 

architecture informs the planning process, but the planning process must also inform 

the development and use of the architecture at each step. Considering “use” in both 

directions will make the architecture more consistent with the transportation plan, 

more responsive to planning needs, and ultimately a more effective tool for planners.

At a fundamental level, the regional ITS architecture provides support to planning for operations by helping planners and 

operators answer the questions below. Small or less complex regions may want to focus their efforts on the using the 

architecture to address one or more of these basic questions. To find the opportunities associated with these questions, look 

for the “Addresses Core Question” call-out boxes in this chapter.

5 What M&O strategies (supported by ITS) may be available to help achieve our operations objectives?

5 What data is available in the region to monitor transportation system performance and track progress toward operations 

objectives?

5 What are the gaps in providing transportation system management and operations across our region?

5 How can we most effectively integrate a new M&O strategy (supported by ITS) with other existing or planned technology 

deployments to provide a greater level of service for the customer?

5 How can we define this M&O project or program in terms of functional requirements, operations concepts, supporting ITS 

standards, etc.?

Read on to find out how the regional ITS architecture can help you respond to these questions and more.

chapter 3 Opportunities for Architecture Use
22

3.1. Establishing Collaboration and Coordination

The regional ITS architecture is at its core a tool for 

collaboration and coordination among agencies involved 

with operations and ITS in a region. It contains information 

about existing and planned systems to increase regionwide 

visibility and coordination of all ITS deployments. Planners 

and implementing agencies use the architecture to identify 

which other agencies in the region need to be involved in a 

project, how ITS elements in a given project should interface with 

neighboring systems, and how the project can leverage other 

deployments to lower costs and provide travelers with seamless 

service. 

This broad, integrated view of the regional transportation system is 

critically important to the objectives-driven, performance-based 

approach to planning for operations. This section will focus on 

leveraging the collaborative relationships and organization formed 

for the regional ITS architecture to support the objectives-driven, 

performance-based approach to planning for operations. 

Sustain and build on the collaborative relationships from the

regional ITS architecture

One of the early steps in the development of a regional ITS architecture is to assemble 

a team of stakeholders and “champions” relevant to and affected by the architecture. 

Planning organizations, operations agencies, and public safety agencies are typically 

important members. This group will build consensus on the ITS services to be put in 

place, understand what is already deployed, and specify how the planned and existing 

systems should interface. 

Many of the agencies and individuals in this team should also be involved in the 

integration of operations into the planning process. The working groups and 

relationships founded for the architecture can be sustained and expanded to lead 

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Regional Collaboration and Coordination

Regional Collaboration and Coordination

Metropolitan or Statewide 

Transportation Plan

Implementation/System Operations

Operations Objectives

Monitoring and Evaluation

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Regional Goals and Motivation

 3.1 Establishing Collaboration and Coordination

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 23

3.1 Establishing Collaboration and Coordination 

planning for operations. Several collaborative groups instrumental in folding 

operations into the planning process and coordinating operations efforts began as 

stakeholder groups for regional ITS architecture development efforts, including:

 Pima Association of Governments Transportation Systems Subcommittee

 Hampton Roads Transportation Operations Subcommittee

 Maricopa Association of Governments ITS Committee

 Metropolitan Washington Council of Governments Transportation Planning Board 

Management, Operations, and Intelligent Transportation Systems Policy Task 

Force and Technical Subcommittee

 Genesee Transportation Council Transportation Management Committee

In Hampton Roads, the leaders of the Transportation Operations Subcommittee credit 

the regional ITS architecture with bringing together planners and operators in the 

region. Thanks to the Transportation Operations Subcommittee’s diverse group of 

stakeholders, including police, first responders, freight operators, and the military, the 

group’s work on planning for operations has in turn made its architecture more robust 

and detailed.

In Rochester, New York, collaboration between planners and operators was formalized 

during the development of the region’s ITS strategic plan. This group, now the 

Genesee Transportation Council’s Transportation Management Committee, is now a 

forum for all operations planning. It is chaired by the MPO and includes operators at 

the local and State levels, as well as local elected officials.

A common challenge is maintaining collaboration after the development or update of a 

regional ITS architecture is finished. Defining a strategic plan for ITS or operations that 

sets out a common purpose and initiatives, can formally extend collaborative 

relationships beyond the lifespan of a single effort. Learn more about ITS and 

operations plans in Section 4.3 of this primer. 

Example

Example

chapter 3 Opportunities for Architecture Use
24

3.2. Developing Goals, Operations Objectives, and

Performance Measures

The initial step in the objectives-driven, performancebased approach is to establish regional goals and 

operations objectives. Goals and objectives that 

focus on the operational performance of the 

transportation system are included in the 

metropolitan or statewide transportation plan to 

guide the inclusion of operations into the 

planning process.

Operations objectives are specific, measurable, 

and agreed-upon statements of desired 

outcomes for regional system performance that 

support the plan’s goals. They may be formed in 

response to influences such as ITS and operations 

staff, elected or appointed officials, or a significant 

event such as a blizzard or traffic incident that draws 

public attention to needed operational improvements. 

Performance measures to track the achievement of operations objectives are 

identified during the development of the objectives and are typically embedded in 

operations objectives. For example, the operations objective: “Improve average travel 

time during peak periods by 5% by year 2018 on regionally significant arterials” is 

tracked by the performance measure “average travel time.” 

The regional ITS architecture can help regions realize these goals and operations 

objectives by using them to organize supportive ITS capabilities and select service 

packages, functional requirements, and project concepts that move the objectives 

toward success. Conversely, architectures and regional ITS strategic plans can help 

planning organizations define operations objectives that reflect available data and the 

expertise of operations staff for metropolitan or statewide transportation plans.

For example, the Champaign Urbana Urbanized Area Transportation Study (CUUATS) 

of Illinois, the transportation-focused arm of region’s MPO, uses the objectives-driven, 

performance-based approach throughout its metropolitan transportation plan. The 

plan contains several operations objectives, performance measures, and strategies to 

reach those objectives. To use the region’s regional ITS architecture to support the 

achievement of the plan’s operations objectives, the region could select service 

packages for the regional ITS architecture that directly map to the strategies and 

operations objectives of the plan. The table below offers a hypothetical example of 

linking objectives and strategies from the CUUATS MTP to service packages:

Implementation/System Operations

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Regional Collaboration and Coordination

Metropolitan or Statewide 

Transportation Plan

Determine Operations Needs

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Define Performance Measures

Regional Goals and Motivation

Operations Objectives

Operations Objectives

Regional Goals and Motivation

Define Performance Measures

 3.2 Developing Goals, Operations Objectives, and Performance Measures

Example

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 25

3.2 Developing Goals, Operations Objectives, and Performance Measures 

Table 1: Hypothetical Example Showing Linkage Between Operations Objective and Strategies from Choices 2035 

Champaign Urbana Urbanized Area Transportation Study Long Range Transportation Plan to Potential Regional ITS 

Architecture Service Packages.14

Objective Strategies Service Packages

Improve average vehicular 

travel time by at least 1.5 

minutes during peak hour 

periods on major traffic 

corridors by 2035

Continue signal upgrades, 

periodic retiming, and 

coordination of all new and 

existing signalized intersections

ATMS03: Traffic Signal Control

Utilize car sharing programs 

and park and ride facilities to 

remove vehicle trips from the 

roadway network

ATIS08: Dynamic Ridesharing 

ATMS16: Parking Facility 

Management

Continue adding connected 

pedestrian, bicycle and 

transit facilities to the existing 

transportation network making 

these travel modes more 

efficient

APTS02: Transit Fixed Route 

Operations

APTS03: Demand Response 

Transit Operations

APTS07: Multimodal 

Coordination

Incorporate operations objectives from the transportation planning process 

into the regional ITS architecture

The regional ITS architecture is a tool to achieve operations objectives developed 

during metropolitan or statewide planning. Architecture stakeholders are asked to 

determine regional needs and the ITS services that address those needs. This 

process parallels the early steps of the objectives-driven, performance-based 

approach and may be combined with those steps. It is crucial that the architecture 

reflect the region’s planning goals and operations objectives so it can effectively 

support the integration of M&O strategies into the planning process.

The Minnesota Statewide Regional ITS Architecture15 is directly linked to the 

Minnesota statewide transportation plan through a table in the architecture that 

connects the goals and policies of the plan to the objectives developed for the ITS 

architecture. Minnesota views ITS as a tool to implement the goals and policies of the 

statewide plan and updates the architecture in coordination with the transportation 

plan. In connection to the transportation plan policies, a comprehensive set of highlevel objectives and related performance measures have been defined as part of the 

Minnesota statewide ITS architecture. ITS Project Concepts have also been 

developed and specifically connected to the objectives in the ITS architecture.

14 Champaign Urbana Urbanized Area Transportation Study, Choices 2035 Champaign Urbana Urbanized Area Transportation 

Study Long Range Transportation Plan, December 2009. Available at: http://www.ccrpc.org/transportation/lrtp2, last accessed 

August 29, 2011. 15 Minnesota Department of Transportation, Minnesota Statewide Regional ITS Architecture, March 2009. Available at:

http://www.dot.state.mn.us/guidestar/2006_2010/regional_architecture/Volume%201%20-%20Overview.pdf, last accessed 

August 29, 2011.

Example

chapter 3 Opportunities for Architecture Use
26

The following table is an excerpt from the architecture that shows the explicit links 

made between ITS development objectives and the policies from the statewide 

transportation plan.

Leverage the operations expertise of the regional ITS architecture stakeholders 

in developing objectives

Meaningful operations objectives for a region require the expertise, input, and 

commitment from operators and related stakeholders. The discussion of regional 

needs, desired systems, and operational concepts required for the regional ITS 

architecture provides a rich opportunity to also develop proposed operations 

objectives based on regional goals. These two steps (developing the regional ITS 

architecture and operations objectives) are not often performed at the same time; 

doing so would allow operators’ on-the-ground knowledge of the transportation 

system to inform the strategic direction set by the region’s leadership. The operators’ 

knowledge of available resources to support potential operations objectives can 

support the development of realistic and achievable objectives. It would also help ITS 

architecture developers base their decisions on a common, specific set of 

performance outcomes to enhance the architecture’s utility when including operations 

in the statewide or metropolitan planning process. 

Even if ITS architecture stakeholders do not develop objectives, the needs and 

services they identify document regional transportation priorities and issues, which 

can be used as a starting point when developing operations objectives for the 

metropolitan or statewide transportation plan.

When a regional ITS strategic plan is developed alongside an ITS architecture, the 

plan may play an even more significant role in developing operations goals and 

objectives. The regional ITS strategic plan’s goals and objectives may have come from 

the regional transportation planning process or may have been separately developed. 

In the latter case, they provide a starting point for the development of operations goals 

and objectives that will drive regional planning for operations.

 3.2 Developing Goals, Operations Objectives, and Performance Measures

1A. TZD and "The Four Es"

1B. System-wide, Cost-Effective SafetyEnhancements

1C. Local Road Safety1D. Air and Rail Safety2A. State Highway Bridge Conditions2B. State Highway Pavement Conditions2C. Other State Highway Infrastructure

2D. Other Transportation Infrastructure

3A. Bridge Inspection, Follow-Up, and

Preventative Maintenance

3B. Level of Highway Maintenance3C. Efficiencies Across All Jurisdictions

3D. Maintenance of Other Modes

O-1 Reduce crashes due to road weather conditions X X X

O-2 Reduce crashes due to unexpected congestion X X X

O-3 Reduce secondary crashes X X X

O-4 Reduce incident clearance time X X X

O-5 Reduce crashes due to red-light running X X X X

O-6 Reduce crashes due to unsafe drivers, vehicles and cargo on the transportation system X X X X

O-7 Reduce lane departure crashes X X X

O-8 Reduce crashes due to roadway/geometric restrictions X X X X

O-9 Reduce crashes at railroad crossings X X X X

O-10 Reduce crashes at intersections X X X X

O-11 Reduce speed differential X X X

O-12 Reduce crashes due to driver errors and limitations X X X X

O-13 Reduce crashes involving pedestrians or non-motorized vehicles X X X X

O-14 Reduce violation of traffic laws X X X X

O-15 Reduce emergency/incident response time X X X X X

O-16 Enhance emergency/incident response effectiveness X X X X X

O-17 Safeguard public safety personnel while they are at roadway incidents and emergencies X X X X

O-18 Reduce speed violations X X X

O-19 Reduce security risks to transit passengers and transit vehicle operators X

O-20 Reduce security risks to motorists and travelers X

O-21 Reduce security risks to transportation infrastructure X

O-22 Reduce exposure due to Hazmat & homeland security incidents X X

O-23 Enhance tracking and monitoring of sensitive Hazmat shipments X X

O-24 Reduce congestion and delay

O-25 Enhance safety of workers X X X X

O-26 Maintain smooth traffic flow X

O-27 Reduce incident detection and verification time X X

O-28 Increase transit ridership

O-29 Enhance transit operations efficiency X

O-30 Increase carpoolers

O-31 Increase throughput of roadways

O-32 Reduce delays at border crossings X

O-33 Keep travelers informed of travel conditions

O-34 Enhance parking facility services and management

O-35 Inform travelers of travel mode options

O-36 Enhance asset and resource management X X X X X X X X X

O-37 Enhance credential process automation

O-38 Reduce freight movement delays due to inspection

O-39 Enhance garage operations efficiency X X

O-40 Reduce commercial vehicle size and weight violations

O-41 Enhance planning with better data X X X X X X X X X

O-42 Enhance investment decision making X X X X X X X X

O-43 Enhance compliance of air quality standards X

O-44 Reduce environmental impacts of de-icing material use

Minnesota ITS Development Objectives

Policy 1. Traveler

Safety

Policy 2. Infrastructure

Preservation

Policy 3. Maintenance and

Security

Figure 15: Minnesota Statewide Transportation Plan to Architecture Mapping.

ITS Project

Concepts (Arch)

Plan Policies

Statewide Transportation

ITS Development

Objectives (Arch)

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 27

3.2 Developing Goals, Operations Objectives, and Performance Measures 

In 2010, the Genesee Transportation Council led the development of the ITS Strategic 

Plan for Greater Rochester. The Genesee Transportation Council and the other 

stakeholders developed goals and objectives for nine system management and 

operations initiatives to guide an ITS deployment strategy. An example goal for 

incident and emergency management was “Provide for prompt, safe response to 

traffic incidents and emergency management scenarios to increase safety and 

minimize congestion, disruptions, and loss of capacity associated with traffic 

incidents.”16 An objective for the public transportation management area was 

“Increase the quality, timeliness, breadth, and availability of transit traveler information, 

leveraging traveler information investments by regional partners.” 17 Such goals and 

objectives in an ITS strategic plan should inform both the regional ITS architecture and 

the M&O component of a metropolitan transportation plan.

Consult the architecture to identify available sources of operations data to 

track measurable objectives

As emphasis increases on developing specific, measurable operations objectives 

when planning for operations, transportation system performance data has become 

more and more important. Identifying and collecting the data needed to track 

operations objectives is a major challenge for regions as they work to implement the 

objectives-driven, performance-based approach. 

Regions are interested in forming operations objectives that they will be able to track with 

existing or planned data sources. Even as early as the definition of operations objectives, 

planners and operators can look to the ITS architecture to see where operations data is 

being generated, where it is compiled, and which agencies have access to it. 

The focal point in the ITS architecture for data collection to support performance 

monitoring is the Archived Data Management Subsystem (ADMS). The relevant areas 

in the regional ITS architecture can be identified by reviewing the architecture 

inventory to identify systems that are associated with the ADMS. These are the data 

collection points in the regional ITS architecture. Depending on how the architecture is 

organized, these data sources may be identified by reviewing interfaces to data 

collection points or the three related Archived Data service packages.

Additional potential data sources that could support operations objectives can also be 

identified by inspecting the Archived Data service packages using the Turbo 

Architecture software.18 Untapped potential data sources can then be incorporated 

into the architecture in the next regional ITS architecture update.

The following diagram from the Fayetteville-Springdale, Arkansas (Northwest 

Arkansas) regional ITS architecture is an example of information from a regional ITS 

architecture that could be used to support the identification of current and future data 

sources for tracking operations objectives. In this example, the MPO is potentially 

collecting data from more than 20 different planned data sources.

16 Genesee Transportation Council, Intelligent Transportation Systems (ITS) Strategic Plan Greater Rochester, February 2011. 

Available at: http://www.gtcmpo.org/Docs/PlansStudies/ITS_StrategicPlanUpdate.pdf, last accessed December 20, 2011. 17 Ibid. 18 Additional information about Turbo Architecture is available in Appendix A.

Addresses Core 

Question:

What data is available 

in the region to monitor 

transportation system 

performance and track 

progress toward

operations objectives?

Example

Example

chapter 3 Opportunities for Architecture Use
28

 3.2 Developing Goals, Operations Objectives, and Performance Measures

maint. and const.

archive data

Traffic Management

AHTD District 4 TMC

+

AHTD District 9 TMC

+

Bella Vista Traffic

Operations Center

+

Benton County Traffic

Management Center

+

Bentonville Traffic

Operations Center

+

Fayetteville Traffic

Operations Center

+

Municipal Traffic

Operations Center

+

Rogers Traffic Operations

Center

+

Siloam Springs Traffic

Operations Center

+

Springdale Traffic

Operations Center

archived data

product requests

Transit Management

Independent School

District Dispatch

+

Ozark Regional Transit

Dispatch

+

Razorback Transit

Dispatch

archive

coordination

AD2 - ITS Data Warehouse

Northwest Arkansas MPO Data Archive

Maintenance and

Construction

Management

AHTD Headquarters

+

Bella Vista Public

Works Department

+

Bentonville

Transportation Division

+

County Maintenance

Operations

+

Fayetteville

Transportation Division

+

Municipal Public Works

+

Rogers Street

Department

+

Siloam Springs Public

Works

+

Springdale Public

Works

Archived Data

User System

Archive Data Users

archive

coordination

Archived Data

Management Subsystem

NWARPC MPO

Data Archive

Archived Data

Management Subsystem

Bi-State MPO

Archive Data

traffic archive

data

archive requests + archive status

archive requests + archive status

archived data

products

archive requests + archive status

transit archive data

Figure 16: Diagram Illustrating the Potential Data Sources Available to the Northwest Arkansas MPO.19

19 Northwest Arkansas Regional Planning Council, “Final Northwest Arkansas Regional ITS Architecture” Web Site, March 2007. Available at:

http://www.consystec.com/arkansas/nwark/web/_regionhome.htm. Last accessed August 29, 2011.

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 29

3.3. Determining Operations Needs

Determining operations needs is critical to developing the most effective 

strategies to achieve operations objectives. This activity examines where, 

when, and why the transportation system is currently not meeting the 

objectives set forth by the region. Without this information, selection and 

application of M&O solutions risks being misdirected and ineffective.

Determining operations needs requires gathering information or data on 

the current state of the transportation system’s performance and 

comparing it to the desired performance outcomes. Data is collected on 

the transportation system to identify the location, duration, and temporal 

extent of performance problems. When data collection is not feasible, 

regions may assess their operations needs by using the expertise of 

operators who are familiar with specific performance issues or 

deficiencies in operations activities, such as lack of retiming signals. 

Data gathering may be performed regularly as part of a region’s 

congestion management process. In transportation management areas 

(areas with populations over 200,000), MPOs are federally required to 

use a systematic process to monitor congestion and propose mitigation 

strategies that include M&O.

Gather information on needs from ITS stakeholders 

The regional ITS architecture also requires the determination of regional needs. 

Because architecture development generally brings together planners and operators 

in the region, it can be an ideal opportunity for inventorying operations needs. 

Needs are collected from existing documents and stakeholder input and include problems 

with the regional transportation system and the associated needs of the operators, 

maintainers, and users of the system. The list of needs in a regional ITS architecture may 

not be driven by the current regional operations objectives and should therefore be taken 

as input to a larger process of identifying needs. Determination of needs for the regional 

ITS architecture should be carefully integrated with other metropolitan and statewide 

transportation planning processes, including the congestion management process.

ITS stakeholders gathered for the architecture may also be able to contribute their 

expertise in identifying where, when, and why transportation system performance 

does not meet current operations objectives. This could serve as a low-cost substitute 

for data collection and may give ideas on issues to strategically study. Importantly, ITS 

stakeholders can provide information on needs related to the operation and 

maintenance of existing ITS, e.g., additional staff and data needed to make timely and 

necessary preventive or responsive maintenance to variable message signs or traffic 

signal infrastructure and communications. 

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Define Performance Measures

Regional Goals and Motivation

Operations Objectives

Regional Collaboration and Coordination

Metropolitan or Statewide 

Transportation Plan

Implementation/System Operations

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Determine Operations Needs

Determine Operations Needs

Monitoring and Evaluation

chapter 3 Opportunities for Architecture Use

3.3 Determining Operations Needs 
30

In the Hampton Roads region of Virginia, the regional ITS architecture committee used 

stakeholder meetings to help identify operations needs for the region. The Minnesota 

DOT used the architecture development process to identify and prioritize needs using 

a voting system among the committee members.

Look for available sources of data in the architecture to measure system 

deficiencies

The interfaces defined in the architecture can be used to identify data sources that 

can help determine operations needs. As mentioned in the section on developing 

goals, operations objectives, and performance measures, sources of data for 

diagnosing system performance issues can be found in the architecture.

Identify gaps in coverage of ITS-supported services in the region

One of the primary purposes of a regional ITS architecture is to ensure that ITS 

elements in a region operate as a system rather than as individual, unrelated 

elements. By creating an inventory of existing and planned ITS deployments in a 

region and defining the connections among these deployments, planners can see 

where ITS elements could be more effective if linked and operated as a system. They 

can also identify geographic and functional gaps in the ITS system. 

For example, data to supply traveler information may not be collected in one county 

within a three-county region. The operators may identify this lack of traveler 

information in one part of the region as a gap that needs to be addressed to meet a 

regional operations objective, such as “provide seamless traveler information to 

travelers on all freeways and significant arterials by 2014.” This type of information 

about gaps in ITS services can be helpful when determining operations needs.

ITS stakeholders in Maricopa County have said that the mapping and discussion of 

ITS projects and deployments helped them identify gaps in their system. This was 

particularly useful for the identifying needs for interconnecting ITS deployments in the 

region.

Figure 17 was created from the Turbo Architecture database for the Maricopa 

Association of Governments Regional ITS Architecture.20 The figure shows the cities 

in the Phoenix metropolitan area that are, or will be, sharing CCTV video on the 

existing metropolitan center-to-center network. As shown, four cities were not 

connected to the video sharing network (shown as dashed “Planned” connections in 

the diagram) when the architecture was last updated. The architecture further 

distinguishes between cities that had deployed CCTV cameras that were not yet 

shared on the network (e.g., City of Avondale) and cities that had not yet deployed 

CCTV cameras at the time the architecture was developed (e.g., City of Tempe). 

These missing connections (dashed lines in the diagram) represent gaps in CCTV 

deployment and traffic image sharing capability between cities that will be added in 

planned projects in Maricopa County. 

20 Maricopa Association of Governments, “Maricopa Association of Governments Regional ITS Architecture” Web Site, June 2010. 

Available at: http://www.consystec.com/mag/web/, last Accessed August 29, 2011.

Addresses Core 

Question:

What are the gaps in 

providing transportation 

system management 

and operations across 

our region?

Example

Example

chapter 3 Opportunities for Architecture Use

 3.3 Determining Operations Needs
Applying a Regional ITS Architecture to Support Planning for Operations 31

Maricopa County Department of Tran...

Phoenix Metropolitan C2C CCTV

Network

City of Goodyear

City of Goodyear TMC

City of Avondale

City of Avondale TMC

City of Surprise

City of Surprise TMC

City of Tempe

City of Tempe TMC

City of Scottsdale

City of Scottsdale TMC

City of Mesa

City of Mesa TMC

City of Chandler

City of Chandler TMC

City of Phoenix

City of Phoenix TMC

City of Glendale

City of Glendale TMC

City of Peoria

City of Peoria TMC

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

traffic images.

Existing

Planned

Figure 17: Identifying and Filling the Gaps in the Phoenix Metropolitan Center to Center CCTV Network.

chapter 3 Opportunities for Architecture Use

3.3 Determining Operations Needs 
32

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Define Performance Measures

Regional Goals and Motivation

Operations Objectives

Regional Collaboration and Coordination

Metropolitan or Statewide 

Transportation Plan

Implementation/System Operations

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Determine Operations Needs

Evaluate M&O Strategies

Select M&O Strategies for the Plan

Identify M&O Strategies

Identify M&O Strategies

Evaluate M&O Strategies

Select M&O Strategies for the plan

Monitoring and Evaluation

Addresses Core 

Question:

What M&O strategies 

(supported by ITS) may 

be available to help 

achieve our operations 

objectives?

3.4. Identifying, Evaluating, and Selecting M&O Strategies

In this part of the objectives-driven, performance-based approach, M&O 

strategies are identified to accomplish regional operations objectives aimed at 

fulfilling transportation needs. M&O strategies are systems, services, projects, 

or programs that aim to maximize the performance of existing and planned 

multimodal infrastructure. They include traffic incident management, traveler 

information services, freight mobility, and transit operations and management. 

These strategies can be implemented alone or as part of transportation 

preservation, safety, or capacity expansion projects. Once M&O strategies are 

identified, they are evaluated and prioritized for selection. Some regions use 

analysis tools such as the ITS Deployment Analysis System or 

dynamic traffic assignment models to quantitatively 

evaluate the proposed M&O strategies. 

There is considerable overlap between the 

identification of M&O strategies and the 

identification and selection of service packages in 

the regional ITS architecture. This section focuses 

on highlighting the opportunity this overlap 

presents for reducing duplication by coordinating 

planning for operations with service package 

selection.

Examine service packages selected in current architectures for

ITS-based M&O strategies

The regional ITS architecture can support the selection of M&O strategies by ensuring 

that planners and their regional operations partners examine the full set of available 

service packages and consider all possible ITS-based operations strategies to 

address needs and deficiencies. If the regional ITS architecture is current and 

developed collaboratively with input from primary operations stakeholders in the 

region, planners and operators can use the selected service packages as an initial 

foundation for the set of M&O strategies to be considered. Since the service packages 

chapter 3 Opportunities for Architecture Use

 3.4 Identifying, Evaluating, and Selecting M&O Strategies
Applying a Regional ITS Architecture to Support Planning for Operations 33

may not have been selected with the regional operations objectives in mind, they will 

need to be evaluated for relevance. The Turbo Architecture Planning Tab21 can be 

used to relate the operations objectives to service packages and identify any 

disconnects that should be addressed. Service package selections may be modified 

through this process, making the architecture more consistent with and useful to 

planning for operations.

The Southeast Michigan Council of Governments views its regional ITS architecture as 

useful information in identifying strategies during its planning for operations activities.

Select service packages in support of the overall metropolitan/statewide 

transportation planning process 

If the region’s architecture is not up to date, consider combining the identification of 

M&O strategies with the selection of service packages. Timing regional ITS 

architecture updates to coincide with integration of operations into a regional 

transportation plan using the objectives-driven, performance-based approach can 

help regions avoid duplicating these highly related activities.

Coordinating architecture updates with the region’s overall planning for operations 

approach helps the architecture become a relevant and essential tool that supports 

operations objectives. With a coordinated approach, a single set of M&O strategies 

can be identified, selected, and recorded in both the transportation plan and regional 

ITS architecture. 

21 Additional information about Turbo Architecture and the planning tab is available in Appendix A.

Example

chapter 3 Opportunities for Architecture Use

3.4 Identifying, Evaluating, and Selecting M&O Strategies 
34

3.5.	Defining Programs and Projects

A transportation plan and transportation 

improvement program (TIP) resulting from the 

objectives-driven, performance-based approach 

to planning for operations contain programs and 

projects that directly support the achievement of 

the region’s operations objectives through the use 

of M&O.

The merit of incorporating a regional ITS 

architecture into this approach is most commonly 

recognized in defining programs and projects; 

several metropolitan areas and States have made 

this their standard practice as a result. The architecture can 

provide a common reference that can transform a list of ITS-related programs 

and projects in a TIP or STIP into a coordinated set of projects that relate to each 

other and to the operations objectives and strategies defined in the transportation 

plan. (See Section 4.1 for more information.) The regional ITS architecture thus 

provides a regional context for local ITS and operations projects.

Define programs and major initiatives in a regional context

A regional program or initiative typically involves many partners and requires 

coordinated efforts to address transportation system operations. For example, a 

regional initiative may involve system operators and public safety agencies in 

collaborative development of an integrated incident management program. With its 

focus on integration, the regional ITS architecture is well-suited for defining broad 

programs and initiatives. It encompasses all of the partners in the regional 

transportation system and includes a high-level view of the systems they operate and 

the opportunities for integration among these systems. 

The architecture can be used to identify all the partners that should be at the table 

when defining a regional transportation operations program, including potential 

stakeholders and systems that may have been missed in the initial vision for the 

program. Consulting the list of stakeholders in the architecture early in the definition of 

the program will help ensure that all relevant partners are included from the outset.

Once the stakeholders are identified, relevant inventory elements, service packages, 

and interfaces can be selected in collaboration with these partners. Using the ITS 

architecture to define a program is largely a matter of defining the applicable 

architecture subset. If the architecture is up to date, the program can be defined as a 

simple subset of the architecture. In other cases, additional definition will be required 

for concepts that were not envisioned in the original architecture, particularly for older 

regional ITS architectures.

Regional Collaboration and Coordination

Implementation/System Operations

Operations Objectives

Regional Goals and Motivation

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Metropolitan or Statewide 

Transportation Plan

Metropolitan or Statewide 

Transportation Plan

Monitoring and Evaluation

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

 3.5 Defining Programs and Projects

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 35

SD Transit

SD Trolley

Private

No Cty Transit

To Planning

and Evaluation

(SANDAG)

Traveler

Information

(Travel TIP)

Freeway

Traffic Mgmt

(D11 TMC)

Information

Service

Provider

Freeway Traffic Data

Emergency

Management

Local Traffic Data

Arterial Traffic

Management

Transit

Operations CTS

To Emergency Mgmt

Freeway Mgmt,

and Arterial Mgmt

From Transit

Signal Priority

Grade Crossing

Static schedules

Dynamic schedules

Incidents

User Statistics

VDS

Signals

CMS

HAR

Shared Control

Auto/Transit/CVO User

Traffic/Route/

Transit Data

From Transit

Congestion

VDS

CMS

RMS

HAR

Public (Call Boxes, Mobile 911)

From Transit

From Transit Patrol/FSP Units

Signal

Preemption

Incidents

Planning and

Evaluation

SD Transit

SD Trolley

Private

No Cty Transit

To Planning

and Evaluation

(SANDAG)

Traveler

Information

(Travel TIP)

Traveler

Information

(Travel TIP)

Freeway

Traffic Mgmt

(D11 TMC)

Freeway

Traffic Mgmt

(D11 TMC)

Information

Service

Provider

Information

Service

Provider

Freeway Traffic Data

Emergency

Management

Emergency

Management

Local Traffic Data

Arterial Traffic

Management

Arterial Traffic

Management

Transit

Operations CTS

To Emergency Mgmt

Freeway Mgmt,

and Arterial Mgmt

From Transit

Signal Priority

Grade Crossing

Static schedules

Dynamic schedules

Incidents

User Statistics

VDS

Signals

CMS

HAR

Shared Control

Auto/Transit/CVO User

Traffic/Route/

Transit Data

From Transit

Congestion

VDS

CMS

RMS

HAR

Public (Call Boxes, Mobile 911)

From Transit

From Transit Patrol/FSP Units

Signal

Preemption

Incidents

Planning and

Evaluation

Planning and

Evaluation

The architecture has been 

very beneficial in the 

implementation of our 511 

system and what we are 

doing for ICM. It provided a 

sound foundation and 

building block for innovative 

and cost-effective concepts.

Samuel Johnson

SANDAG 

The program definition process is likely to identify additional stakeholders and 

integration opportunities. Once created, the program definition will show how each 

partner fits in the overall program. It also provides a regional context for the program, 

identifying peripheral stakeholders and systems, including future systems that will be 

implemented through other programs and projects.

For example, the San Diego Association of Governments (SANDAG) used its 

architecture to support the initial definition and development of its Integrated Corridor 

Management (ICM) program. In turn, the decision support system defined for the ICM 

program helped the regional ITS architecture better reflect the use of decision support 

systems to support regional traffic management. Figure 18 shows a high-level 

architectural view of the Intermodal Transportation Management System, the heart of 

the regional ITS architecture and the basis of San Diego’s ICM program.

Figure 18: San Diego Intermodal Transportation Management System High-Level Architecture.22

22 San Diego Association of Governments, San Diego I-15 Integrated Corridor Management (ICM) System: Final ICM Concept of 

Operations, May 2009.

Example

chapter 3 Opportunities for Architecture Use

3.5 Defining Programs and Projects 
36

Define project scope and identify integration opportunities

A primary goal of planning is to ensure that project money is spent wisely. This means 

that projects defined and developed by different local agencies should be compatible, 

working together as a cohesive regional system. There should also be a mechanism 

to ensure that local projects accomplish the regional objectives defined in the 

transportation plan. The regional ITS architecture can help planners and their 

operations partners meet these goals.

Using an ITS architecture for project scoping is not markedly different than using it for 

program definition. The difference is the breadth and level of detail— projects tend to 

be more narrowly focused and more specific than programs. The architecture subset 

selected for a project will typically include fewer stakeholders, systems, and interfaces 

than the subset for a program and will require a relatively minor time investment to 

create.

As individual projects are independently scoped and defined, there is a risk of 

fragmentation and disconnects from other projects and regional objectives. Defining 

every ITS project in terms of the same regional ITS architecture helps integrate new 

projects (and related M&O strategies) with existing and planned deployments, 

minimizing the risk of disconnects and ultimately improving the level of service offered 

by the transportation system when the projects are implemented. 

The approach to defining a project using the regional ITS architecture depends on 

how the architecture is defined. In the simplest case, the project will already be 

defined in the architecture documentation, and the relevant portion of the architecture 

can be extracted directly from its documentation. Figure 15 shows an example project 

diagram taken directly from the Maricopa County Association of Governments 

Regional ITS Architecture.23

If the desired project is not already defined, the project sponsor will need to scan the 

regional ITS architecture to find the stakeholders, inventory elements, service 

packages, and interfaces the project will need. It is strongly recommended that project 

sponsors include peripheral interfaces that show how the project fits into the broader 

regional transportation system in their project definitions. This process results in a 

project scope that considers the context of all of the other systems in the region, 

resulting in an initial project scope that is more accurate and less subject to change. 

For example, the use of the regional ITS architecture to scope the flood monitoring 

project in Figure 19 would result in early analysis to determine whether the interface to 

the National Weather Service should be included. Using the architecture results in 

more accurate scope for the projects included in the TIP, minimizing later amendments 

to the TIP to add more funding to projects that were not sufficiently scoped in planning.

23 Maricopa Association of Governments, “Maricopa Association of Governments Regional ITS Architecture” Web Site, June 2010. 

Available at: http://www.consystec.com/mag/web/, last accessed August 29, 2011.

Addresses Core 

Question:

How can we most 

effectively integrate a 

new M&O strategy 

(supported by ITS) with 

other existing or 

planned technology 

deployments to provide 

a greater level of 

service for the 

customer?

Example

chapter 3 Opportunities for Architecture Use

 3.5 Defining Programs and Projects
Applying a Regional ITS Architecture to Support Planning for Operations 37

3.5 Defining Programs and Projects 

Figure 19: Using Service Package Customization to Define Projects in the Maricopa Association of Governments Regional ITS Architecture.

MC03 - Road Weather Data Collection

Flood Control District of Maricopa County

Weather Service

National Weather 

Service

environmental

conditions data

Roadway Subsystem

Flood Control 

District of 

Maricopa County 

Weather Sensors

Maintenance and 

Construction

Management

Flood Control 

District of 

Maricopa County 

ALERT

environmental

conditions data status

environmental sensor 

data

environmental sensors

control

Traffic Management

ADOT TOC

environmental sensor

data

environmental conditions 

data

chapter 3 Opportunities for Architecture Use
38

3.6. Selecting and Prioritizing Projects

The objectives-driven, performance-based process flow diagram 

depicts direct top-down flow from the transportation plan to the S/TIP. 

In the objectives-driven, performance-based approach M&O project 

selection and prioritization is based on the ability of the project to fulfill 

the area’s operations objectives. Typically, there are many other 

factors and influences in the project selection process including 

funding and staff required for ongoing operations. The regional ITS 

architecture provides an important tool for ensuring that M&O projects 

support a regionally integrated vision for operations and its enabling 

technology. If the architecture was constructed or updated in response 

to the operations objectives from the region’s transportation plan, the 

architecture can also help to link project selection and prioritization to 

the region’s objectives. The architecture can help provide continuity 

between the transportation plan and the transportation improvement 

program.

Define an efficient timeline for project implementation

One of the significant differences between operations/ITS projects and conventional 

transportation projects is the degree to which information, facilities, and infrastructure 

can be shared among the projects. For example, a 511 traveler information system 

project may use traffic information collected by previous instrumentation projects and 

incident information from a CAD integration project. The regional ITS architecture 

provides a new way to look at these ITS project relationships or “dependencies.” 

Project dependencies can identify projects that must be implemented before other 

projects can begin. Taking these dependencies into account enables an efficient 

sequence to be developed so that projects build incrementally on each other, saving 

money and time as the region invests in future ITS projects.

Project sequencing is a basic component of most regional ITS architectures. 

Commonly, regional ITS architectures include a list of short-, medium-, and long-range 

projects. To better support the programming of operations/ITS project, the project 

sequencing in the architecture should take dependencies between projects into 

account. It also should reflect the real-world sequencing already defined in 

programming documents. 

The Memphis, Tennessee regional ITS architecture presents projects by market 

package; grouping projects that contribute to a common service. The table below, 

extracted from the Memphis regional ITS architecture, illustrates both recommended 

and supporting projects for a “high priority” market package: Traffic Incident 

Management System (ATMS08). These tables can assist the Memphis region in 

developing a sequence of projects for implementation with the “recommended 

projects” occurring prior to the “additional supporting projects.” 

Implementation/System Operations

Metropolitan or Statewide 

Transportation Plan

Regional Collaboration and Coordination

Operations Objectives

Regional Goals and Motivation

Systematic Process To Develop and 

Metropolitan or Statewide Select M&O Strategies To Meet Objectives

Transportation Improvement Program 

or Other Funding Programs

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Example

chapter 3 Opportunities for Architecture Use

 3.6 Selecting and Prioritizing Projects
Applying a Regional ITS Architecture to Support Planning for Operations 39

Table 2: Memphis Regional ITS Architecture Projects Related to Incident Management.24

Traffic Incident Management System (ATMS08) High Priority

Manages both unexpected incidents and planned events so that the impact to the transportation 

network and traveler safety is minimized. This market package includes incident detection 

capabilities and coordination with other agencies. It supports traffic operations personnel in 

developing an appropriate response in coordination with emergency management, maintenance and 

construction management, and other incident response personnel.

Recommended Projects

• Municipal TOC Coordination with TDOT Region 4 SmartWay TMC

• Municipal/County TOC

• Municipal/County TOC Coordination with Municipal/County Public Safety Dispatch

• TDOT Region 4 SmartWay TMC Coordination with MDOT Northwest Regional TMC

• TDOT SmartWay Information System Modification for Municipal Traffic Information Input

Additional Supporting Projects

• Municipal Service Patrol Implementation

• Municipal/County Portable DMS

• TDOT HELP Service Patrol Expansion

• TDOT Region 4 SmartWay ITS I-40 Extension

• TDOT Region 4 SmartWay ITS SR 385 Extension

• TDOT Region 4 SmartWay ITS SR 385/I-269 (North) Implementation

• TDOT Region 4 SmartWay ITS SR 385/I-269 (South) Implementation

Because project sequences are closely related to the TIP or STIP, they have a shorter 

shelf life than the rest of the architecture and should be updated in conjunction with 

major TIP or STIP updates. In Albuquerque, New Mexico, the Mid-Region Council of 

Governments and New Mexico DOT have developed an efficient approach to 

capturing project-level updates in their regional ITS architecture. They release an 

architecture addendum with each release of the TIP that shows the TIP projects in the 

architecture context. The baseline regional ITS architecture document is updated less 

frequently.

Include the architecture as part of the TIP or STIP project application process

Once the scope of each project has been defined, there must be a regional 

mechanism to examine the scope of each project and identify potential disconnects 

and missed opportunities. In effect, local agency project sponsors define the pieces of 

the puzzle in their project applications. Planning and operations staff must work 

together to look across the pieces and verify that they will fit together. The MPO 

frequently provides this regional oversight in a metropolitan area, as the State DOT 

does at the State level. The TIP or STIP project application should provide the 

information necessary to understand how a given project fits into the regional context.

24 Memphis Urban Area MPO and Tennessee Department of Transportation, Memphis Urban Area Regional ITS Architecture: 

Regional ITS Deployment Plan, June 2010, Available at: http://www.kimley-horn.com/Projects/TennesseeITSArchitecture/

documents/memphis/Memphis%20Regional%20ITS%20Deployment%20Plan.pdf, last accessed August 28, 2011.

Example

chapter 3 Opportunities for Architecture Use

3.6 Selecting and Prioritizing Projects 
40

Many regions require project sponsors to identify the portion of the regional ITS 

architecture their project will implement as part of the TIP application. Done properly 

(i.e., with more depth than just “checking a box”), this requires project sponsors to 

consider the regional context for their projects. It also provides information in the 

application that the MPO or DOT can review to verify conformance with the regional 

ITS architecture and any operations plans for the region. This is particularly important 

for regionally significant projects that may also be prioritized by defined project 

selection criteria.

In the Northern Region of the Virginia DOT, the Virginia DOT has provided operations 

project applicants with a Project Proposal Template. Excerpts from this template are 

shown below. The template is part of the 2009 Virginia DOT’s Northern Virginia 

Operations Planning Guide: Leveraging ITS Architecture and Systems Engineering.

25

The template asks applicants to summarize and check off the ITS strategic plan’s 

goals and objectives that this project will meet. The applicants are also asked to 

specify the operations needs that the project will address and “provide information 

related to the component of the Northern Virginia ITS Architecture that are associated 

with this project.”26 The stakeholders, ITS architecture elements or subsystems, and 

ITS market packages associated with the proposed project are also requested as part 

of the operations project proposal template. This template facilitates a direct 

connection between the programming of ITS/operations projects and the regional ITS 

architecture and strategic plan. 

25 Virginia Department of Transportation, Northern Virginia Operations, Operations Planning Guide: Leveraging 

ITS Architecture and Systems Engineering, June 2009. Available at: http://www.vdot-itsarch.com/docs/

PlanningandProgramDeliveryGuideV1%282009-11-17%29.pdf, last accessed August 28, 2011. 26 Ibid.

Example

 3.6 Selecting and Prioritizing Projects

Appendix A: Project Proposal Template 

1 PROJECT OVERVIEW

PROVIDE PROJECT OVERVIEW TEXT HERE INCLUDING PROJECT PURPOSE, LIMITS AND EXPECTED 

OUTCOMES

2 GOALS AND OBJECTIVES

PROVIDE SUMMARY TEXT OF STRATEGIC PLAN GOALS AND OBJECTIVES MET BY THIS PROJECT

VDOT’s vision for the region and also for the Project Corridor is to:

Make Roadway Travel Safe, Efficient, and Reliable.

To meet this vision, VDOT NRO plans to achieve through this project by: (example below)

•	 Serving the public by providing them with the information they need to make good travel decisions;

•	 Monitoring real-time traffic conditions and the condition of its infrastructure;

•	 Proactively and rapidly identifying problems, including traffic congestion, crashes, and other mobility

and safety needs;

•	 Taking rapid and effective action to address current and developing problems, appropriately applying

a range of methods including physical improvements and advanced technologies;

•	 Sharing information, coordinating responses, and planning jointly with its partner agencies.

Goals and objectives met by this project include:

FOR EASE OF USE, PLACE AN “X” IN THE CELLS TO THE LEFT OF THE GOALS AND OBJECTIVES THAT WILL BE 

ADDRESSED BY THIS PROJECT

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 41

6 PROJECT ARCHITECTURE

PROVIDE INFORMATION RELATED TO THE COMPONENTS OF THE NORTHERN VIRGNIA ITS 

ARCHITECTURE THAT ARE ASSOCIATED WITH THIS PROJECT. The Project Architecture provides a 

framework that identifies the institutional agreement and technical integration necessary to interface 

the ITS project with other ITS projects and systems. It addresses the application of the proposed 

system with a focus on integration and operation of the system(s). The NRO Regional ITS Architecture 

(www.vdot-itsarch.com/Default.htm) should be used as the basis for generating the project 

architecture. The section should summarize key stakeholders (e.g. VOT NRO, Private Sector ISPs, 

MATOC, Video Clearinghouses), elements (e.g. VDOT NRO MPSTOC – TOC CCTV Cameras, VDOT NRO 

MPSTOC – TOC Detection, VDOT NRO MPSTOC – TOC DMS, and VDOT NRO MPSTOC – TOC, etc.), and 

ITS Market Packages description and interconnect diagram impacted by the proposed project. 

GOALS AND OBJECTIVES

[ Mark the goals and objectives that apply to this project with an “X” ] EXPECTED BENEFITS

Goal #1: Reduce Congestion •	Reduction in travel

times

•	Reduction in delay

(vehicle hours)

•	Reduction in incident

duration

•	Improved travel time

reliability

1.1 Reduce travel times and delays for all modes along identified major corridors

1.2 Improve travel time reliability on major corridors

1.3 Actively manage travel demand on NRO facilities

1.4 Reduce delays due to work zones and planned special events

1.5 Reduce incident clearance times

Goal #2: Improve Safety

•	Reduction in

incidents

2.1 Reduce vehicular crashes

2.2 Reduce pedestrian and bicyclist crashes

Figure 20: Excerpt from Project Proposal Template in the 2009 Virginia DOT’s Northern Virginia Operations Planning Guide: Leveraging 

ITS Architecture and Systems Engineering.

chapter 3 Opportunities for Architecture Use

3.6 Selecting and Prioritizing Projects 
42

What is Systems Engineering and Why is it Important?

Systems engineering is an organized approach to developing and implementing a system. The approach can be 

applied to any system development. Whether you are deploying a few CCTV cameras, upgrading your traffic signal 

system, or implementing a sophisticated transportation management system, systems engineering can be used. The 

International Council on Systems Engineering (INCOSE) defines systems engineering like this: 

"Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It 

focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem."27

Although there are many ways to represent the systems engineering process, the winged “V” (or “Vee”) model 

shown in Figure 21 has been broadly adopted in the transportation industry.

Figure 21: The Systems Engineering "V" Model.

Following the “V” process from left to right, the left wing shows the regional ITS architecture, feasibility studies, and 

concept exploration that support initial identification and scoping of an ITS project. As you move down the left side 

of the “V”, system definition progresses from a general user view of the system to a detailed specification of the 

system design. A series of documented baselines are established including a concept of operations that defines 

the user needs, a set of system requirements, and high-level and detailed design. The hardware and software are 

procured or built at the bottom of the “V”, and the components of the system are integrated and verified on the right 

side. Ultimately, the completed system is validated to measure how well it meets the user’s needs. The right wing 

includes the operations and maintenance, changes and upgrades, and ultimate retirement of the system. 

A systems engineering analysis is required for all ITS projects using Federal funds per Title 23 CFR 940.11. Visit 

http://ops.fhwa.dot.gov/int_its_deployment/sys_eng.htm for additional information and resources including the 

Systems Engineering Handbook (http://ops.fhwa.dot.gov/publications/seitsguide/index.htm) and Systems 

Engineering Guidebook (http://www.fhwa.dot.gov/cadiv/segb/).

27 International Council on Systems Engineering, "What is Systems Engineering?" Web Site, June 2004. Available at: http://www.incose.org/practice/whatissystemseng.aspx, 

last accessed December 20, 2011.

Feasiblity Study

/ Concept 

Exploration

Concept of 

Operations

System

Requirements

High-Level

Design

Detailed

Design

Regional

Architecture(s)

Changes

and

Upgrades

Retirement /

Replacement

Operations

and

Maintenance

System

Validation

System

Verification &

Deployment

Subsystem

Verification 

Unit / Device

Testing 

Software / Hardware 

Development Field 

Installation

Lifecycle Processes

Development Processes

Implementation

Document Approval

Unit / Device

Test Plan

Subsystem

Verification Plan

(Subsystem Acceptance)

System Verification Plan

(System Acceptance)

System Validation Plan

Time Line

Decomposition and Definition

Integration and Recomposition

 3.7 Implementation and System Operations

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 43

3.7. Implementation and System Operations

A regional ITS architecture is an important tool in assisting agencies 

with project development and system operations. The architecture 

supports the early steps of the systems engineering process used to 

guide the lifecycle of ITS-based operations projects. Developing the 

project’s concept of operations, system requirements, and system 

design are all early elements of the systems engineering that can be 

supported by the use of the regional ITS architecture. Additionally, the 

relationships, roles and responsibilities, and institutional agreements 

specified in the architecture can help in ongoing system operations.

Use the architecture to kick-start project development

The portion of the architecture selected during project definition can 

support project development once funds are committed and the 

project is initiated. As shown in Figure 22, many components of the 

regional ITS architecture provide an initial input to support systems 

engineering. 

Regional ITS architecture content such as the stakeholders, their roles and 

responsibilities (included in the operational concept), and the list of agreements 

supports the project concept of operations. The functional requirements are high-level 

requirements that can support system requirements development, and the interfaces 

and ITS standards support project design. In addition to assisting project implementers 

in the preliminary engineering stage, planners may also benefit from participating in 

the conceptual development of projects and strategies prior to the start of the formal 

project development. These components can inform creation of project documents, 

including requests for proposals, and architectural details can inform the project’s 

scope of work. 

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Metropolitan or Statewide 

Transportation Plan

Regional Collaboration and Coordination

Operations Objectives

Regional Goals and Motivation

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Implementation/System Operations

Implementation/System Operations Monitoring and Evaluation

3.7 Implementation and System Operations 

System

Requirements

Concept of

Operations

High-Level

Design

Detailed

Design

Stakeholders

Inventory Elements

Operational Concepts

Functional Requirements

Interfaces

ITS Standards

Agreements

Portion of the

Regional ITS

Architecture

Figure 22: Using the Regional ITS Architecture to Support Project Development.

How can we define an 

M&O project or program in 

terms of functional 

requirements, operations 

concepts, supporting ITS 

standards, etc.?

Addresses Core 

Question:

chapter 3 Opportunities for Architecture Use
44

For example, stakeholders contemplating an Active Traffic Management project would 

find several relevant service packages: Variable Speed Limits, Dynamic Lane 

Management and Shoulder Use, and Dynamic Roadway Warning, which includes 

support for queue warnings.28 Other more basic service packages including Traffic 

Metering and Traffic Information Dissemination would also be relevant and associated 

with the project. Other service packages, like Speed Enforcement, might also be 

considered but excluded from the first phase of the project. For a simple project, it 

would be easy to compile the relevant parts of the architecture by hand, but for a 

significant project like this ATM project, the stakeholders should use Turbo 

Architecture29 to quickly assemble the pieces of the regional ITS architecture that 

apply to the initial ATM project into an ATM project architecture. 

In addition to the relevant service packages, the related inventory (the State DOT 

freeway management center and associated field elements), stakeholders, functional 

requirements, interfaces, standards, and agreements are extracted and included in 

the project architecture. Numerous decisions are made along the way as functional 

requirements are omitted that are associated with border crossings (not applicable), 

environmental monitoring (future phase), and dynamic truck restrictions (only in the 

vicinity of the port). After some discussion, the stakeholders elect to also include 

requirements associated with hard shoulder running. Similar decisions are made when 

including interfaces in the project architecture as architecture flows associated with 

variable speed limits, lane management, roadway (including queue) warning, and 

shoulder management are all included. As a result of this process, the stakeholders 

develop a project architecture that defines the functional scope of the project and 

includes a set of high-level requirements, interfaces, and associated ITS standards. 

The stakeholders can use their project architecture to support project development, 

including development of a concept of operations and requirements for a statement of 

work and RFP.

Leverage agency roles and responsibilities and interagency agreements 

needed to operate the implemented system 

The regional ITS architecture contains information on the current and future roles and 

responsibilities of ITS stakeholders that support the operation of regional ITS systems. 

These roles and responsibilities are typically identified in collaborative working 

sessions during architecture development or updates. These sessions also often 

identify agency agreements that would be required for implementation and operation 

of the defined systems. Agencies developing multijurisdictional projects or programs 

similar to those defined in the architecture can use this information to move faster and 

avoid duplicating effort. Of course, the exact roles, responsibilities, and agreements 

will need to be adjusted based on the exact specifications of the implemented system.

28 This discussion reflects Version 7.0 changes to the National ITS Architecture. Consult the National ITS Architecture web site 

(www.iteris.com/itsarch/) for the current set of service packages related to Active Traffic Management. 29 Additional information about Turbo Architecture is available in Appendix A.

 3.7 Implementation and System Operations

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 45

3.8. Monitoring and Evaluation

Ongoing monitoring and evaluation is crucial for the successful application 

of M&O strategies to accomplish specific operations objectives. It also 

provides important accountability among transportation professionals and 

with the public and elected leaders. The evaluation of M&O strategies 

following implementation enables practitioners to baseline overall system 

performance and estimate the value of their transportation operations 

investments. 

The regional ITS architecture can play an important role in monitoring the 

operational performance of the transportation system, evaluating M&O 

strategies, and identifying data sources to support regional planning. There 

are two primary aspects of operational performance that should be 

monitored: the performance outcomes from the perspective of the user 

(how well is the system performing the task of providing mobility to the 

community) and the performance of the ITS and human operators (how 

well ITS/operations services are performing the functions they were 

designed to deliver). Both aspects require collection and monitoring of 

operational data, and both can be supported by the regional ITS 

architecture.

Support planning for transportation system performance monitoring

The regional ITS architecture identifies the types of data collected by different 

agencies using different systems. For example, traffic signal systems collect traffic 

volume data; transit operators collect bus, light rail transit (LRT), and heavy rail arrival 

times and passenger occupancies; and third-party providers collect and report speeds 

and congestion levels on freeways and arterials.

A region’s mobility objectives may be established in terms of total travel distance and 

time on the network; the amount of delay in the network, perhaps during different 

times of the day and days of the week; travel times by different modes; and travel 

statistics for vehicles, passengers, and freight. Because collecting data using surveys 

is expensive and only reports performance as a snapshot in time, there is substantial 

advantage if the data can be collected, collated, analyzed, and reported automatically 

and continuously.

The regional ITS architecture can clearly show which performance measures can be 

quantified using data available from the various ITS systems and subsystems in the 

region. Processes and procedures for using the data can then be defined. This may 

require modifying the architecture or updating service packages and associated 

interfaces to include additional data collection and reporting capabilities.

3.8 Monitoring and Evaluation 

Metropolitan or Statewide 

Transportation Improvement Program 

or Other Funding Programs

Metropolitan or Statewide 

Transportation Plan

Regional Collaboration and Coordination

Operations Objectives

Regional Goals and Motivation

Systematic Process to Develop and 

Select M&O Strategies to Meet Objectives

Implementation/System Operations

Monitoring and Evaluation

Monitoring and Evaluation

Real-Time System 

Management Information 

Program: SAFETEA-LU

Section 1201

The information about the 

types of system performance 

data collected across the 

region in the regional ITS 

architecture can support the 

establishment of a real-time 

system management 

information program to collect 

and provides timely, accurate 

traffic and travel condition 

information to the public and 

share this data with other 

public agencies. 

For more information: 

www.ops.fhwa.dot.gov/1201/.

chapter 3 Opportunities for Architecture Use
46

The focal point in the architecture for performance data collection is the Archived Data 

Management Subsystem (ADMS). Planners and operators can identify the relevant 

areas in their regional ITS architectures by reviewing the inventory to identify systems 

associated with ADMS. These are the data collection points in the regional ITS 

architecture. Depending on how the architecture is organized, these data sources may 

be identified by reviewing interfaces to data collection points or the three related 

Archived Data service packages.

Additional potential data sources that could support operations objectives can also be 

identified by inspecting the Archived Data service packages using the Turbo 

Architecture software.30 Untapped potential data sources can then be incorporated 

into the architecture in the next regional ITS architecture update.

In Rochester, New York, the ITS architecture’s data warehousing element provides 

guidance to planners and system managers on data that can be used to evaluate the 

performance of projects. For example, archived vehicle counts and speed information 

provide the ability to quantify the operational impacts of infrastructure and ITS projects 

after they are deployed.

Consolidate system performance measures across agencies within a region

When transportation performance is measured, it is typically done for a single 

jurisdiction or mode. For example, a State DOT may record information about highway 

congestion, while city public works departments may collect delay data on the 

adjacent arterial roads. In parallel, transit operators may record information about the 

on-time performance of buses on routes that may include arterials and highways. Far 

less frequently are agencies across a region able to get a multi-jurisdictional, 

multimodal view of the operating performance of the regional transportation system. 

For example, rarely is the measurement of a freeway incident management system 

broad enough that it consolidates the measurements of performance on the arterials 

and transit systems to document the impacts of incidents and the benefits of the 

incident management system in a comprehensive fashion.

The regional ITS architecture exists to prevent data stovepiping and encourage 

regional solutions to broad problems such as incident management in a corridor. 

Examining the ITS architecture will identify data that is available or that could be 

collected by each system in the corridor. The ITS architecture can be used to identify 

opportunities to consolidate data for more comprehensive measurement of 

parameters that are currently measured and reported for only some agencies or for 

some components of the transportation system.

30 Additional information about Turbo Architecture is available in Appendix A.

Example

 3.8 Monitoring and Evaluation

chapter 3 Opportunities for Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 47

Example

In Albuquerque, New Mexico, a new initiative has been identified to create a regional 

data archive system that will span all of the stakeholders and systems in the region. 

Though still in the early concept development stage, the goal is to use the defined 

regional ITS architecture linkages to consolidate all collected data in a regional data 

warehouse that will compliment current travel data collection activities. The data can 

then be analyzed to provide comprehensive system performance measures as well as 

support project development and the CMP.

Support planning for improved measurement of operating agencies’ 

performance

The two previous opportunities relate to measurement of the operational performance 

of the transportation system. This opportunity concerns measurement of the efficiency 

of an agency in performing its operations activities. 

Operating agencies measure the performance of their operations staff using key 

indicators of effectiveness and efficiency. For example, a freeway service patrol may 

measure parameters such as “time to respond to requests for assistance” and “time to 

clear incidents after arriving at the scene.” An automatic incident-detection system will 

be evaluated by the percentage of incidents detected, the number of false alarms, and 

the delay between incident occurrence and detection. 

These performance measures are typically agency-specific and often do not cross 

agency boundaries. Like broader transportation system performance measures, 

performance monitoring of operations components can also be planned at a regional 

level using the regional ITS architecture. The architecture itself can be used to identify 

opportunities for monitoring operations performance and overall transportation system 

performance. 

A regional approach to performance monitoring allows complementary elements 

operated by different agencies to be assessed in context rather than in isolation, 

enabling better identification of operations components whose performance could be 

improved. For example, management of an incident may involve reporting through 911, 

deployment of an freeway service patrol (FSP) vehicle, deployment of DOT crews to 

clear debris and perform repairs, and deployment of specialty towing and salvage 

services. The ITS architecture provides an opportunity to plan ways to automate this 

process and the data collection and monitoring of each facet of the incident response 

and its impact on the performance of the transportation system.

3.8 Monitoring and Evaluation 

chapter 3 Opportunities for Architecture Use

Applying a Regional ITS Architecture to Support Planning for Operations 49

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.

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

4 Creating a Planning-Supportive Architecture

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.

chapter 4 Creating a Planning-Supportive Architecture
50

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 

1.

2.

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 51

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.

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 

Regional goals and motivation

Operations objectives

Monitoring and evaluation

Metropolitan transportation plan

Implementation

M&O strategies

Systematic process to develop and 

select M&O strategies to meet objectives

Transportation improvement program and 

other funding programs

Iterative Process

Step #6: 

Maintain the Architecture

Step #5: 

Use the Architecture

Need│Scope│Champions│Stakeholders

Step #1: Get Started 

Inventory│Needs and Services│

Operational Concept│

Functional Requirements

Step #2: Gather Data

Interconnects│Information Flows

Step #3: Define Interfaces

Project Sequencing│ITS Standards│

List of Agency Agreements

Step #4: Implementation

1

2

Figure 23: Key Connections in the Context of the Planning and Architecture Processes.

chapter 4 Creating a Planning-Supportive Architecture
52

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”31 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. 

31 Additional information about Turbo Architecture is available in Appendix A.

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

Architecture

Scope

Needs & Services

Agreements

MTP/LRSTP

Goals

Objectives

Strategies

Objectives Services

O1: AD1:

O2: ATMS04:

Strategies Services

S1: APTS02:

S2: EM01:

OR

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 53

 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.

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

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 

32 Planning View is planned for inclusion in Version 7.0 of the National ITS Architecture.

chapter 4 Creating a Planning-Supportive Architecture
54

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:

1. 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.

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.

3. 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 

Architecture

Scope

Needs & Services

Agreements

STIP/TIP

Projects

Projects with ITS

Projects 

with ITS

Projects from 

Sequencing

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

OR

Projects 

with ITS

Architecture 

Portion 

(Inventory, 

Interfaces,...)

OR

Projects 

with ITS

Services

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 55

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 nearterm 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.

Figure 26: MRCOG Regional ITS Infrastructure Geodatabase.33

33 Image courtesy of the Mid-Region Council of Governments.

Regional ITS Infrastructure Geodatabase

Rio Metro

City of

Albuquerque

NMDOT

Bernalillo

County

ABQ Ride MRCOG

City of

Rio Rancho

chapter 4 Creating a Planning-Supportive Architecture
56

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.

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 57

 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. 

chapter 4 Creating a Planning-Supportive Architecture
58

 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. 

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 

MTP/LRSTP/(S)TIP

Regional ITS 

Arc

hitecture

ITS/Operations Plan

Figure 27: An ITS/Operations Plan Can Connect the Regional ITS 

Architecture with the Region's Transportation Plan and Program. 

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 59

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.

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.

Figure 28: Adding Planning Context with an ITS/Operations Plan.

MTP/LRSTP

STIP/TIP

PROJECTS

Vision

Goals/Objectives

Needs

Funding Considerations

M&O Strategies

Project Specifics

• Location/Extent

• Costs

• Benefits

PROJECTS

ITS /

OPERATIONS PLAN

REGIONAL ITS 

ARCHITECTURE

chapter 4 Creating a Planning-Supportive Architecture
60

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.

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.

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.

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

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. 

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 61

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

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.

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. 

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. 35 Virginia Department of Transportation, Northern Region Operations ITS Decision Support Tool. Available at:

http://www.vdot-itsdst.com/, last accessed December 20, 2011.

chapter 4 Creating a Planning-Supportive Architecture
62

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. 

Figure 30: VDOT ITS Decision Support Tool - Cost and Benefit Data36

36 Virginia Department of Transportation, Northern Region Operations ITS Decision Support Tool. Available at

http://www.vdot-itsdst.com/, last accessed December 20, 2011.

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.

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 

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 63

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. 

Kesla Valley 2035 Metropolitan 

Transportation Plan 

Operations Objectives:

• Reduce traveler delay on freeways and major 

arterials by 5% in 10 years

.

.

.

Kesla Valley

TIP 2012-2017

Kesla Valley Regional ITS Architecture

Traffic Incident Management Service Package

• Inventory and Stakeholders

• Operational Roles and Responsibilities

• Functional Requirements

• Interfaces

RCTO Operations Objective: • Decrease incident clearance time on freeways and major

arterials by 25% in 5 years...

Kesla Valley RCTO for Traffic 

Incident Management

Relationships and Procedures:

• Develop a regional incident management team

• Hold after-action reviews

• Increase shared knowledge and awareness of roadway

conditions across agencies....

Resource Arrangements:

• ...

Physical Improvements:

• Implement CCTV sharing between TMCs in Kesla Valley region 

and 911 call center. Feed State Police CAD data into TMCs.

Approach:

• Reduce time at each element of TIM including detection

and notification of incident with an emphasis on improved

coordination across agencies and jurisdictions...

Kesla Valley RCTO for Traffic 

Incident Management

Figure 31: Connecting an RCTO, a Plan, and an Architecture.

chapter 4 Creating a Planning-Supportive Architecture
64

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

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. 

TIP

2007

TIP

2009 TIP

2007

Architecture

Addendum

2009

Metropolitan

Transportation Plan

Baseline Regional

ITS Architecture

Figure 32: Architecture Updates to Support Planning.

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 65

Table 5: Architecture and Transportation Plan Update Scheduling Options.

Option Pros Cons

1. Architecture Updated In Parallel with 

MTP/LRSTP

Best of Both Worlds: Architecture 

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/

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/LRSTP 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.

MTP/LRSTP

Update

Architecture

Update

Time

MTP/LRSTP

Update

Architecture

Update

Time

MTP/LRSTP

Update

Architecture

Update

Time

chapter 4 Creating a Planning-Supportive Architecture
66

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.

Figure 33: Excerpt from AMPA Regional ITS Architecture Addendum37

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.

Category I. Traffic Management, Incident

Management, Maintenance Operations Projects, 

and Studies

BLACK text = Completed or Projects in 2010-2015 TIP

BLUE text = Projects programmed in 2012-17 TIP

MTP/TIP Project Database Information ITS Regional Architecture Information and TIP Project Descriptions

Seq.

MPO ID TIP 

Yr Project Name in TIP Lead Agency

Proj 

Type

Recommended MPs in 

Regional Architecture

Agency-Proposed Project 

Market Packages (MPs) – Use 

This Column for Project MPs

1 all NMRoads.COM NMDOT ITS ITS-TSM ATIS01,2 ATIS01,2

2 48.7 10 I-25 Safety Project NMDOT ITS ITS-TSM ATMS01, ATMS06

3 103.0 11-17 Albuquerque T M S Abq DMD ITS-TSM ATMS01, 03 AMTS01, 3, 6, AD1, APTS9*

4 464.0 10-12 Unser Blvd Connection (Middle) Abq DMD Capacity ATMS01, 3, APTS9* ATMS01, 3, APTS9*

5 585.1 11 Wyoming Blvd Widening Ph I Abq DMD Capacity ATMS03 AD1, ATMS01, 3

6 585.3 11 Wyoming Blvd Widening Ph II Abq DMD Capacity ATMS01,3 AD1, ATMS01, 3

7 587.0 11-17 Great Streets Abq DMD misc ATMS01, 3, 6, AD1, APTS9*

8 616.0 10 Coors Corridor Study Abq DMD misc All MPs

Figure 33: Excerpt from AMPA Regional ITS Architecture Addendum.37

chapter 4 Creating a Planning-Supportive Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 67

5 Your Action Plan for More Productive 

Architecture Use

This chapter provides recommendations for how you can advance the use of your 

region’s regional ITS architecture in planning for operations. 

Figure 34 shows the three key leverage points that can be used to improve 

capability and efficiency in any area, including the use of an ITS architecture 

in transportation planning. The three aspects that are shown are the major 

determinants of cost, schedule, and quality: the people involved, the 

technologies/tools that they use, and the processes and practices that are 

established. Your action plan should consider all three aspects so that your 

region can adopt a balanced approach that improves the skills of the people 

involved, arms those people with high quality tools (e.g., an improved, 

planning-supportive architecture), and adopts documented processes that 

help to ensure the capability improvements are sustainable in the long run. 

The following sections provide recommendations that employ all three 

leverage points: people, process, and tools. 

5.1. Establish Support

Regional ITS architecture use will only gain traction if it has support from 

decisionmakers. The executive summary and Chapter 1 from this primer can be used 

to help make the case with MPO and State DOT decisionmakers that drive the 

transportation planning processes. In general, the case is best made by identifying the 

tangible benefits of regional ITS architecture use as described in Section 1.1. 

Regulatory requirements for architecture use in planning also provide motivation. See 

Appendix B for relevant requirements in 23 CFR 450 and 23 CFR 940. Once 

decisionmaker support has been established, it may be helpful to develop a regional 

policy regarding improved architecture use in planning for operations. This will help 

ensure continuity even as decisionmakers are replaced. Additionally, it is important to 

establish a collaborative forum to coordinate and lead the effort that includes 

stakeholders with a vested interest in planning for operations and the regional ITS 

architecture. This may be an ad hoc committee or a new item of business within an 

existing policy or technical committee. 

5.2. Self-Assessment

Once you have decisionmaker support, the next step is to perform an unbiased 

assessment of the region’s capability to productively use the regional ITS architecture 

in planning. Figure 35 shows a basic capability maturity model that can be used to 

assess your region’s capability in this area. The incremental capabilities reflect a 

natural progression from basic architecture updates to documented, productive use of 

the regional ITS architecture in planning. This model can also be used to plan and 

measure your region’s improvements over time.

While this chapter is focused on 

measuring and improving 

capability in the specific area of 

architecture use in planning for 

operations, other resources are 

available for transportation 

agencies seeking broader 

process improvement guidance. 

For example, the AASHTO 

Systems Operations and 

Management Guidance at

www.aashtosomguidance.org/ 

includes a set of evaluation tools 

and process improvement 

guidance covering all facets of 

transportation system 

operations and management. 

The Capability Maturity Model 

Integrated (CMMI) provides 

strong process improvement 

guidance for all aspects of 

project development and 

acquisition at

www.sei.cmu.edu/cmmi/.

Process People

Tools

Figure 34: Three Leverage Points for Capability 

Improvement.

chapter 5 Your Action Plan for More Productive Architecture Use
68

As shown, a region’s ability to use a regional ITS 

architecture in planning begins with the architecture 

itself. Does the architecture reflect input from planners, 

and does it include components that are ready for use in 

planning? Architecture use will not be productive until 

these criteria are met. Refer to Chapter 4 for a broad 

range of architecture improvements that are oriented 

towards making the architecture ready for use in 

transportation planning. At the next capability level, the 

quality architecture is actually used in planning, as 

evidenced by consistency and interconnection of the 

architecture and related plan(s). The third level, 

“managed” architecture use and maintenance, is 

governed by regional or agency processes so that architecture use is better supported 

and more resilient to agency personnel changes. 

Table 6 includes self-assessment questions you can ask to measure your region’s 

architecture use in planning. The assessment tool presented in Table 6 should be 

regarded as a starting point for assessing the degree to which the architecture is 

used. It is not a comprehensive tool covering all aspects of architecture use, but it will 

help clarify certain areas and identify opportunities for future improvement.

Table 6: Self-Assessment for Use of Regional ITS Architecture in Planning for Operations.

Not 

Achieved

Partially 

Achieved

Mostly 

Achieved

Fully 

Achieved

1. Architecture Supports Planning (Ready for Use)

A01 The architecture (and ITS strategic 

plan) includes a detailed description 

of how the architecture is 

incorporated and used in the 

metropolitan or statewide planning 

process. 

A02 Planners from the MPO and/or 

State DOT were involved in 

developing/maintaining the 

architecture (and ITS strategic 

plan). 

A03 The architecture (and ITS strategic 

plan) makes an explicit connection 

to operations objectives or 

operations goals in the metropolitan 

or statewide transportation plan. 

Figure 35: Architecture Use for Planning Capability Levels

Managed

Used

Ready for

Use

Architecture use in planning is guided by 

regional/agency processes that are 

maintained, used and refined over time

Regional architecture and plan(s) 

are consistent and include crossreferences or other evidence of 

actual use

Architecture reflects 

input form planners 

and is ready to 

support planning

1

2

3

chapter 5 Your Action Plan for More Productive Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 69

Not 

Achieved

Partially 

Achieved

Mostly 

Achieved

Fully 

Achieved

A04 The architecture (and ITS strategic 

plan) is used to identify an up-todate sequence of ITS projects.

A05 The architecture (and ITS strategic 

plan) includes projects that directly 

support or implement M&O 

strategies in the plan. 

A06 The region has developed an ITS 

strategic plan or similar document 

that provides a planning context for 

the architecture. It includes:

A06a Vision, goals, objectives 

A06b Strategies for ITS deployment

A06c Funding considerations

A06d Detailed project definitions and cost 

estimates

A06e Benefits analysis

A07 The architecture includes inventory 

elements that support data 

collection and performance 

monitoring that support planning. 

2. Demonstrated Use of the Architecture

U01 The architecture was updated to 

support the last update of the 

related metropolitan/statewide 

transportation plan.

U02 The metropolitan/statewide plan 

identifies M&O strategies that are 

defined in the architecture (or ITS 

strategic plan).

U03 The projects identified in the 

architecture (or ITS strategic plan) 

are integrated into the STIP/TIP.

U04 The metropolitan/statewide 

transportation plan contains 

language that refers to the ITS 

architecture and how it is linked to 

the plan.

chapter 5 Your Action Plan for More Productive Architecture Use
70

Not 

Achieved

Partially 

Achieved

Mostly 

Achieved

Fully 

Achieved

3. Managed Use of the Architecture

M01 A regional stakeholder organization 

or committee has been identified to 

monitor and manage architecture 

use and maintenance.

M02 A documented policy is in place 

that supports use of the architecture in the planning process.

M03 Procedures that define the process 

that is used to develop the metropolitan/statewide transportation 

plan cover architecture use.

M04 The STIP/TIP application process 

for ITS projects includes identification of the relevant portion of the 

regional ITS architecture. 

M05 The transportation project

prioritization process takes into 

consideration how proposed 

projects support the regional ITS

architecture. 

5.3. Take Action

Once you assess where your region stands in the above capability model, it is time to 

take small, incremental steps toward increased capability. It will take time to progress 

all the way up the highest capability level, but major benefits can be gained through 

making a few basic improvements. Below is a sorted list of actions that correspond to 

achieving greater capability in applying the architecture to planning for operations.

Organize for Use

 Hold one or more meetings that bring together the regional ITS architecture 

developers with transportation planners in your region to discuss the function of the 

regional ITS architecture and its potential for use. Ask planners to identify any 

issues or challenges in planning for operations that may be better addressed by 

use of the architecture. For example, the need for data to support system 

monitoring and performance measurement could be addressed by defining data 

warehouse capabilities in the regional ITS architecture that would support data 

reporting and archiving.

 Determine if a regional planning for operations collaborative group exists in your 

region. If so, meet with the leaders and ask if the regional ITS architecture can be 

included within the scope of the group. If a group does not exist, form a multiagency collaborative group that spans those involved with integrating operations 

into the region’s planning process as well as regional ITS architecture developers/

participants.

 If you do not already have one, identify an architecture champion or champions for 

the region.

chapter 5 Your Action Plan for More Productive Architecture Use
Applying a Regional ITS Architecture to Support Planning for Operations 71

Build Professional Capacity

 Take advantage of training courses and workshops in regional ITS architecture 

use and maintenance and Turbo Architecture available through U.S. DOT 

including the National Highway Institute and the Consortium for ITS Training and 

Education. Visit http://www.its.dot.gov/arch or contact your FHWA Division Office for 

more information.

 If your regional ITS architecture is not ready for use, plan an update to incorporate 

some of the improvements described in Chapter 4. If desired, a “Quick-Start” 

workshop can be conducted for your region that assesses your current 

architecture, develops a “Concept of Use” that defines how your region will use the 

architecture in planning and project development, and develops an action plan for 

your architecture update. Contact your FHWA Division Office for more information. 

Align Regional ITS Architecture with Operations in Transportation Planning 

Process

 Align the regional ITS architecture with the region’s goals and operations 

objectives. This is a step that will be implemented over time as needs and services 

in the architecture are updated to reflect the region’s desired operations outcomes.

 Seek out information on operational needs from the region’s transportation 

planning documents. The congestion management process, if one exists, could be 

a good source of information on transportation performance issues related to 

congestion. Integrate those needs into the needs identified in the regional ITS 

architecture.

 Identify M&O strategies in the region’s plan(s) and work toward including service 

packages in the architecture that support the plan’s strategies.

 Update the sequenced list of projects in the regional ITS architecture to reflect the 

latest STIP/TIP. 

Use Regional ITS Architecture to Support Planning for Operations

 Search the architecture for sources of data that could support monitoring system 

performance and any operations objectives in the region’s transportation plan. 

Involving the region’s planners, contact the agencies responsible for the data and 

discuss possibilities for use of data in operations planning.

 Work with operations project/program implementing agencies to define and 

develop ITS-based projects with the contextual information provided in the 

architecture.

 Update the STIP/TIP project application process to require project applications to 

identify how the project fits with the regional ITS architecture.

chapter 5 Your Action Plan for More Productive Architecture Use

Applying a Regional ITS Architecture to Support Planning for Operations 73

This primer has noted several opportunities for improving the linkage between the 

regional ITS architecture and planning for operations through the use of the Turbo 

Architecture software. Examples included:

• Connecting objectives and strategies from the region’s plan(s) with services in 

the regional ITS architecture

• Identifying potential data sources in the region

• Defining projects in the STIP/TIP in terms of the regional ITS architecture

Turbo Architecture is a powerful tool for creating, maintaining, and using regional and 

project ITS Architectures. Turbo Architecture supports many of the requirements 

defined in FHWA’s 23 CFR 940 Rule and the equivalent FTA Policy. This Rule/Policy 

requires ITS projects funded through the Highway Trust Fund to conform to the 

National ITS Architecture and applicable standards. Turbo Architecture uses the 

National ITS Architecture as a template that can be customized and tailored for your 

region or project. For example, Turbo allows you to define the interface between 

specific traffic and transit operations centers in your state or metropolitan area based 

on the general interface defined in the National ITS Architecture.

The Turbo Architecture user interface is built 

around a series of tabs that guide you through the 

process of defining an architecture. For example, 

the Planning Tab shown in Figure 37 is used to 

establish the linkages between the architecture and 

the planning process that are described in this 

primer.

A Turbo Architecture

Figure 36: Turbo Architecture Uses the National ITS Architecture

Traffic

Management

Transit

Management

National ITS

Architecture

Traffic

Management

Transit

Management

Regional/Project

ITS Architecture

Appendix A Turbo Architecture
74

Figure 37: Turbo Architecture Tabbed Interface - The Planning Tab,

As you define an architecture in Turbo, you progress from left to right across each of 

the tabs to identify the objectives and strategies, involved stakeholders, inventory of 

existing and planned systems, services, roles and responsibilities, functional 

requirements, interfaces, standards, and agreements that apply to the architecture. 

Turbo also helps you establish the connections between each of these components. 

For example, you define the stakeholders that own and operate each part of the 

inventory and the ITS services that support each transportation objective. The same 

basic process can be used whether you are defining the overall architecture for a state 

or metropolitan area or a specific architecture for a particular project. In either case, 

you will have defined all of the key components of an ITS architecture by the time you 

reach the right-most tab in the Turbo interface.

Turbo Architecture can also be used to quickly access and create a variety of outputs 

for an architecture. Many outputs are available for display, print, or publication as web 

pages, diagrams, Microsoft Word documents, and Microsoft Excel worksheets. Turbo 

is a Windows-compatible application that uses a standard Microsoft Access database 

to store the architecture content, providing another option for integration with other 

applications.

Appendix A Turbo Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 75

Figure 38: Turbo Architecture Provides Many Output Options.

More on the Planning Tab

Turbo Architecture Version 5.0 was expanded to include a Planning Tab that provides 

an explicit connection between the regional ITS architecture and the transportation 

planning process. By using the new Planning Tab, you can better align the architecture 

with the region’s transportation planning process. In turn, the Planning Tab can 

provide improved traceability between plan objectives, performance measures, M&O 

strategies, and ITS. The tab is configurable to provide links to any output of the 

planning process— goals, policies, objectives, strategies, or any other output from 

your regional planning process can be included on the Planning Tab. By default, the 

Planning Tab specifically supports the objectives and M&O strategies associated with 

the objectives-driven, performance-based approach to planning for operations. Figure 

39 shows a close-up on the right-side of the Planning Tab as a user enters an 

operations objective.

Every M&O objective can be entered into the tab along with a reference to the source 

transportation plan. The defined objectives may then be associated with service 

packages like Transit Fixed-Route Operations and Transit Fleet Management. 

Marina County Inventory

Element Name Status Stakeholder

Alfredo County Freeway Management Center Planned Alfredo County Department of

Transportation

Bus Operations Center Existing Peninsula Area Service Transit

Authority

City Operations Center Existing Saucelito City Department of

Transportation

Communications for Alfredo Networking and

Operations Local Infrastructure

Planned Alfredo County Department of

Transportation

County Traveler Kiosk Network Planned Marinara County Department

of Transportation

Digital Map Products Planned National Digital Traveler

Marinara County Department of Tran...

TOMATO Event Parking System

Marinara County Department of Tran...

TOMATO Regional Traveler

Information

MCDOT and State Highway Patrol

Marinara County Freeway

Management Center (BASIL and

PINCH)

Saucelito City Department of Transpo...

City Operations Center

Sun-Dried Mall, County Gov Offices, ...

Parking lots larger than 200 spaces

Peninsula Area Service Transit Autho...

Bus Operations Center

parking information

parking lot reservation confirmation

parking lot data request

parking reservations request

parking demand management response

parking information

parking demand management request

parking lot inputs

parking demand management response

parking information

parking demand management request

parking lot inputs

parking coordination

parking information

Planned

Future

Marinara Regional ITS 

Architecture

Created By Turbo Architecture

Marinara COG

8/27/2011

Appendix A Turbo Architecture
76

Creating these linkages provides a cross-check that can aid both the objectivesdriven, performance-based approach and the regional ITS architecture. Reports 

identifying potential disconnects may reveal objectives that are not associated with 

service packages and service packages that are not associated with objectives, 

suggesting that either the service package is not needed to support operational 

objectives or that an operations objective is missing from the list. 

Performance measures developed through the objectives-driven, performance based 

approach can also be associated with the regional ITS architecture. The Planning Tab 

allows performance measures to be defined and associated with operations 

objectives, M&O strategies, and service packages. Linking performance measures to 

the architecture in this way allows the performance measures to be consistently 

defined across the region and associated with relevant service packages in a 

systematic way. This enables differences in performance measures to be reconciled to 

establish a uniform system for performance monitoring and evaluation. 

Using the Planning Tab, specific objectives and/or strategies can also be linked to 

individual programs and projects, providing an explicit connection between projects 

and the earlier steps in the objectives-driven, performance-based approach.

For More Information

The Windows-compatible Turbo Architecture software is sponsored by U.S. DOT and 

is available for free download. The software includes a user manual, a quick-start 

guide, and other documentation to help you get started with the tool. Visit the Turbo 

Architecture Support Page (http://www.iteris.com/itsarch/html/turbo/turbomain.htm) for 

more information.

Figure 39: A Closer Look at the Right Side of the Planning Tab.

1. State the objective

2. Optional additional 

information

3. Source reference

4. Performance measures 

for the objective

5. ITS services that support 

the objective

6. Projects that support the 

objective

Appendix A Turbo Architecture
Applying a Regional ITS Architecture to Support Planning for Operations 77

SAFETEA-LU Requirements

1.1. Management & Operations and Architecture in the Planning Process38

On August 10, 2005, the Safe, Accountable, Flexible, and Efficient Transportation Equity Act: A 

Legacy for Users (SAFETEA-LU) was signed into law and became the most recent 

reauthorization of the Nation's surface transportation program. Along with identifying Federal 

funding for a range of transportation programs and other transportation-related regulations, 

SAFETEA-LU updated requirements for metropolitan transportation planning. A final planning 

rule (23 CFR Part 450) was issued on February 14, 2007. Beginning July 1, 2007, all newly 

adopted metropolitan transportation plans must comply with Federal regulations identified in 

SAFETEA-LU and the associated planning rule.

According to the planning rule, "Promote efficient system management and operation" is one of 

the eight planning factors that must be addressed in metropolitan transportation plans. A second 

factor, “Enhance the integration and connectivity of the transportation system, across and 

between modes, for people and freight” is directly supported by regional ITS architecture use in 

planning. Below is an excerpt from the Statewide Transportation Planning; Metropolitan 

Transportation Planning; Final Rule, February 14, 2007, Federal Register. (Bold added to 

highlight points related to operations. Bold italics added to highlight points related to ITS 

architecture.)

§ 450.306 Scope of the metropolitan transportation planning process.

(a) The metropolitan transportation planning process shall be continuous, cooperative, and 

comprehensive, and provide for consideration and implementation of projects, strategies, and 

services that will address the following factors:

(1) Support the economic vitality of the metropolitan area, especially by enabling global 

competitiveness, productivity, and efficiency;

(2) Increase the safety of the transportation system for motorized and non-motorized users;

(3) Increase the security of the transportation system for motorized and non-motorized users;

(4) Increase accessibility and mobility of people and freight;

(5) Protect and enhance the environment, promote energy conservation, improve the quality of 

life, and promote consistency between transportation improvements and State and local planned 

growth and economic development patterns;

(6) Enhance the integration and connectivity of the transportation system, across and 

between modes, for people and freight;

(7) Promote efficient system management and operation; and

(8) Emphasize the preservation of the existing transportation system.

38 The section is taken from U.S. DOT, Advancing Metropolitan Planning for Operations: An Objectives-Driven, Performance-Based Approach – A 

Guidebook, 2010, FHWA-HOP-10-026. Available at: http://www.ops.fhwa.dot.gov/publications/fhwahop10026/index.htm.

B Regulatory Requirements

Appendix B Regulatory Requirements
78

(b) Consideration of the planning factors in paragraph (a) of this section shall be 

reflected, as appropriate, in the metropolitan transportation planning process. The 

degree of consideration and analysis of the factors should be based on the scale and 

complexity of many issues, including transportation system development, land use, 

employment, economic development, human and natural environment, and housing 

and community development.

(c) The failure to consider any factor specified in paragraph (a) of this section shall not 

be reviewable by any court under title 23 U.S.C., 49 U.S.C. Chapter 53, subchapter II 

of title 5, U.S.C. Chapter 5, or title 5 U.S.C. Chapter 7 in any matter affecting a 

metropolitan transportation plan, TIP, a project or strategy, or the certification of a 

metropolitan transportation planning process.

(d) The metropolitan transportation planning process shall be carried out in 

coordination with the statewide transportation planning process required by 23 U.S.C. 

135 and 49 U.S.C. 5304.

(e) In carrying out the metropolitan transportation planning process, MPOs, States, 

and public transportation operators may apply asset management principles and 

techniques in establishing planning goals, defining TIP priorities, and assessing 

transportation investment decisions, including transportation system safety, 

operations, preservation, and maintenance, as well as strategies and policies to 

support homeland security and to safeguard the personal security of all motorized and 

non-motorized users.

(f) The metropolitan transportation planning process shall (to the maximum extent 

practicable) be consistent with the development of applicable regional intelligent 

transportation systems (ITS) architectures, as defined in 23 CFR part 940.

The Final Rule also strengthens expectations for including management and 

operations strategies in the transportation planning process. The Rule states that 

metropolitan transportation plans shall include both long-range and short-range 

strategies/actions, including operational and management strategies that improve the 

performance of existing transportation facilities to relieve congestion and maximize 

the safety and mobility of people and goods.

Selected excerpts are presented below (bold added to highlight points related to 

operations):

§ 450.322 Development and content of the metropolitan transportation plan.

(a) The metropolitan transportation planning process shall include the development of 

a transportation plan addressing no less than a 20-year planning horizon as of the 

effective date. In nonattainment and maintenance areas, the effective date of the 

transportation plan shall be the date of a conformity determination issued by the 

FHWA and the FTA. In attainment areas, the effective date of the transportation plan 

shall be its date of adoption by the MPO.

(b) The transportation plan shall include both long-range and short-range 

Appendix b Regulatory Requirements
Applying a Regional ITS Architecture to Support Planning for Operations 79

strategies/actions that lead to the development of an integrated multimodal 

transportation system to facilitate the safe and efficient movement of people and 

goods in addressing current and future transportation demand.

...

(f) The metropolitan transportation plan shall, at a minimum, include:

(1) The projected transportation demand of persons and goods in the metropolitan 

planning area over the period of the transportation plan;

(2) Existing and proposed transportation facilities (including major roadways, transit, 

multimodal and intermodal facilities, pedestrian walkways and bicycle facilities, and 

intermodal connectors) that should function as an integrated metropolitan 

transportation system, giving emphasis to those facilities that serve important national 

and regional transportation functions over the period of the transportation plan. In 

addition, the locally preferred alternative selected from an Alternatives Analysis under 

the FTA's Capital Investment Grant program (49 U.S.C. 5309 and 49 CFR part 611) 

needs to be adopted as part of the metropolitan transportation plan as a condition for 

funding under 49 U.S.C. 5309;

(3) Operational and management strategies to improve the performance of 

existing transportation facilities to relieve vehicular congestion and maximize 

the safety and mobility of people and goods;

(4) Consideration of the results of the congestion management process in 

[Transportation Management Areas] TMAs that meet the requirements of this subpart, 

including the identification of [single-occupancy vehicle] SOV projects that result from 

a congestion management process in TMAs that are nonattainment for ozone or 

carbon monoxide;

2.1. Transportation Systems Management and Operations39

The SAFETEA-LU Technical Corrections Act of 2008 amended Section 101(a) of Title 

23 U.S.C. to include a definition of transportation systems management and 

operations (TSM&O). TSM&O is also referred to as "management and operations" or 

"M&O."

Below is an excerpt from the SAFETEA-LU Technical Corrections Act of 2008:

(h) Transportation Systems Management and Operations Defined– Section 101(a) of 

title 23, United States Code, is amended by adding at the end the following: 

(39) TRANSPORTATION SYSTEMS MANAGEMENT AND OPERATIONS—

(A) IN GENERAL– The term 'transportation systems management and operations' 

means an integrated program to optimize the performance of existing infrastructure 

through the implementation of multimodal and intermodal, cross-jurisdictional 

39 This section is taken from U.S. DOT, Advancing Metropolitan Planning for Operations: An Objectives-Driven, PerformanceBased Approach – A Guidebook, 2010, FHWA-HOP-10-026. Available at:

http://www.ops.fhwa.dot.gov/publications/fhwahop10026/index.htm.

Appendix B Regulatory Requirements
80

systems, services, and projects designed to preserve capacity and improve security, 

safety, and reliability of the transportation system.

(B) INCLUSIONS- The term 'transportation systems management and operations' 

includes–

(i) regional operations collaboration and coordination activities between transportation 

and public safety agencies; and

(ii) improvements to the transportation system, such as traffic detection and 

surveillance, arterial management, freeway management, demand management, work 

zone management, emergency management, electronic toll collection, automated 

enforcement, traffic incident management, roadway weather management, traveler 

information services, commercial vehicle operations, traffic control, freight 

management, and coordination of highway, rail, transit, bicycle, and pedestrian 

operations.

3.1. Congestion Management Process40

SAFETEA-LU also made a significant change regarding congestion management. 

Title III Section 3005 and Title VI Section 6001 updated the requirement for 

addressing congestion in Transportation Management Areas, mandating the 

incorporation of a "congestion management process" (CMP) within the metropolitan 

planning process.

The law requires a CMP in TMAs – urban areas with a population greater than 

200,000 – as opposed to a congestion management system (CMS). The change in 

name (and acronym) is intended to be a substantive change in perspective and 

practice intended to encourage targeted areas to address congestion management 

through a process that provides for effective M&O and an enhanced linkage to both 

the planning process and the environmental review process that is based on 

cooperatively developed travel demand reduction and operational management 

strategies and capacity increases. This new focus retains the traditional role of the 

MPO in long-range transportation planning, but empowers the MPO and its partners 

in planning for the ongoing operations and management of the transportation system.

Below is language from the Statewide Transportation Planning; Metropolitan 

Transportation Planning; Final Rule, February 14, 2007, Federal Register (bold added 

to highlight points related to operations. Bold italics used to highlight areas 

related to architecture.):

Sec. 450.320 Congestion management process in transportation management 

areas.

(a) The transportation planning process in a TMA shall address congestion 

management through a process that provides for safe and effective integrated

40 This section is taken from U.S. DOT, Advancing Metropolitan Planning for Operations: An Objectives-Driven, PerformanceBased Approach – A Guidebook, 2010, FHWA-HOP-10-026.

Available at: http://www.ops.fhwa.dot.gov/publications/fhwahop10026/index.htm.

Appendix b Regulatory Requirements
Applying a Regional ITS Architecture to Support Planning for Operations 81

management and operation of the multimodal transportation system, based on a 

cooperatively developed and implemented metropolitan- wide strategy, of new and existing 

transportation facilities eligible for funding under title 23 U.S.C. and title 49 U.S.C. Chapter 53 

through the use of travel demand reduction and operational management strategies.

(b) The development of a congestion management process should result in multimodal 

system performance measures and strategies that can be reflected in the metropolitan 

transportation plan and the TIP. The level of system performance deemed acceptable by State 

and local transportation officials may vary by type of transportation facility, geographic location 

(metropolitan area or subarea), and/ or time of day. In addition, consideration should be given 

to strategies that manage demand, reduce single occupant vehicle (SOV) travel, and 

improve transportation system management and operations. Where the addition of general 

purpose lanes is determined to be an appropriate congestion management strategy, explicit 

consideration is to be given to the incorporation of appropriate features into the SOV

project to facilitate future demand management strategies and operational improvements

that will maintain the functional integrity and safety of those lanes.

(c) The congestion management process shall be developed, established, and implemented as 

part of the metropolitan transportation planning process that includes coordination with 

transportation system management and operations activities. The congestion management 

process shall include:

(1) Methods to monitor and evaluate the performance of the multimodal transportation system, 

identify the causes of recurring and nonrecurring congestion, identify and evaluate alternative 

strategies, provide information supporting the implementation of actions, and evaluate the 

effectiveness of implemented actions;

(2) Definition of congestion management objectives and appropriate performance

measures to assess the extent of congestion and support the evaluation of the effectiveness of 

congestion reduction and mobility enhancement strategies for the movement of people and 

goods. Since levels of acceptable system performance may vary among local communities, 

performance measures should be tailored to the specific needs of the area and

established cooperatively by the State(s), affected MPO(s), and local officials in

consultation with the operators of major modes of transportation in the coverage area;

(3) Establishment of a coordinated program for data collection and system performance 

monitoring to define the extent and duration of congestion, to contribute in determining the 

causes of congestion, and evaluate the efficiency and effectiveness of implemented actions. To 

the extent possible, this data collection program should be coordinated with existing data sources 

(including archived operational/ITS data) and coordinated with operations managers in the 

metropolitan area;

(4) Identification and evaluation of the anticipated performance and expected benefits of

appropriate congestion management strategies that will contribute to the more effective use 

and improved safety of existing and future transportation systems based on the established 

performance measures. The following categories of strategies, or combinations of strategies, are 

some examples of what should be appropriately considered for each area:

(i) Demand management measures, including growth management and congestion pricing;

Appendix B Regulatory Requirements
82

(ii) Traffic operational improvements;

(iii) Public transportation improvements;

(iv) ITS technologies as related to the regional ITS architecture; and

(v) Where necessary, additional system capacity;

(5) Identification of an implementation schedule, implementation responsibilities, and 

possible funding sources for each strategy (or combination of strategies) proposed for 

implementation; and

(6) Implementation of a process for periodic assessment of the effectiveness of 

implemented strategies, in terms of the area's established performance 

measures. The results of this evaluation shall be provided to decisionmakers and the 

public to provide guidance on selection of effective strategies for future implementation.

(d) In a TMA designated as nonattainment area for ozone or carbon monoxide 

pursuant to the Clean Air Act, Federal funds may not be programmed for any project 

that will result in a significant increase in the carrying capacity for SOVs (i.e., a new 

general purpose highway on a new location or adding general purpose lanes, with the 

exception of safety improvements or the elimination of bottlenecks), unless the project 

is addressed through a congestion management process meeting the requirements of 

this section.

(e) In TMAs designated as nonattainment for ozone or carbon monoxide, the 

congestion management process shall provide an appropriate analysis of 

reasonable (including multimodal) travel demand reduction and operational 

management strategies for the corridor in which a project that will result in a 

significant increase in capacity for SOVs (as described in paragraph (d) of this 

section) is proposed to be advanced with Federal funds. If the analysis demonstrates 

that travel demand reduction and operational management strategies cannot fully 

satisfy the need for additional capacity in the corridor and additional SOV capacity is 

warranted, then the congestion management process shall identify all reasonable 

strategies to manage the SOV facility safely and effectively (or to facilitate its 

management in the future). Other travel demand reduction and operational 

management strategies appropriate for the corridor, but not appropriate for 

incorporation into the SOV facility itself, shall also be identified through the congestion 

management process. All identified reasonable travel demand reduction and 

operational management strategies shall be incorporated into the SOV project or 

committed to by the State and MPO for implementation.

(f) State laws, rules, or regulations pertaining to congestion management systems or 

programs may constitute the congestion management process, if the FHWA and the 

FTA find that the State laws, rules, or regulations are consistent with, and fulfill the 

intent of, the purposes of 23 U.S.C. 134 and 49 U.S.C. 5303.

23 CFR Rule 940 is the FHWA rule related to ITS architecture and standards which 

governs the regional ITS architecture development.

Appendix b Regulatory Requirements
Applying a Regional ITS Architecture to Support Planning for Operations 83

4.1. ITS Architecture and Standards

In January 2001, FHWA published 23 CFR 940 (ITS Architecture and Standards) and 

FTA published a companion policy to implement Section 5206(e) of TEA-21. This 

Rule/Policy seeks to foster regional integration by requiring that all ITS projects funded 

from the Highway Trust Fund be in conformance with the National ITS Architecture 

and officially adopted standards. “Conformance with the National ITS Architecture” is 

defined in the final Rule/Policy as using the National ITS Architecture to develop a 

“regional ITS architecture” that would be tailored to address the local situation and ITS 

investment needs, and the subsequent adherence of ITS projects to the regional ITS 

architecture. This Rule/Policy continues under the current Federal transportation act. 

While most of the requirements in Rule 940 relate to regional ITS architecture 

development (940.9) and use in project development as part of the systems 

engineering process (940.11), there are several parts of the rule that are relevant to 

architecture use in planning. Planning-related quotes are highlighted with bold 

italics.

§ 940.5 Policy

ITS projects shall conform to the National ITS Architecture and standards in 

accordance with the requirements contained in this part. Conformance with the 

National ITS Architecture is interpreted to mean the use of the National ITS 

Architecture to develop a regional ITS architecture, and the subsequent adherence of 

all ITS projects to that regional ITS architecture. Development of the regional ITS 

architecture should be consistent with the transportation planning process for 

Statewide and Metropolitan Transportation Planning.

§ 940.9 Regional ITS architecture.

(a) A regional ITS architecture shall be developed to guide the development of ITS 

projects and programs and be consistent with ITS strategies and projects 

contained in applicable transportation plans. The National ITS Architecture shall 

be used as a resource in the development of the regional ITS architecture. The 

regional ITS architecture shall be on a scale commensurate with the scope of ITS 

investment in the region. Provision should be made to include participation from the 

following agencies, as appropriate, in the development of the regional ITS 

architecture: Highway agencies; public safety agencies (e.g., police, fire, emergency/

medical); transit operators; Federal lands agencies; State motor carrier agencies; and 

other operating agencies necessary to fully address regional ITS integration.

§ 940.11 Project implementation.

(a) All ITS projects funded with highway trust funds shall be based on a systems 

engineering analysis.

(b) The analysis should be on a scale commensurate with the project scope.

(c) The systems engineering analysis shall include, at a minimum:

Appendix B Regulatory Requirements
84

(1) Identification of portions of the regional ITS architecture being implemented (or if 

a regional ITS architecture does not exist, the applicable portions of the National 

ITS Architecture);

(2) Identification of participating agencies roles and responsibilities;

(3) Requirements definitions;

(4) Analysis of alternative system configurations and technology options to meet 

requirements;

(5) Procurement options;

(6) Identification of applicable ITS standards and testing procedures; and

(7) Procedures and resources necessary for operations and management of the 

system.

(d) Upon completion of the regional ITS architecture required in §§ 940.9(b) or 

940.9(c), the final design of all ITS projects funded with highway trust funds shall 

accommodate the interface requirements and information exchanges as specified 

in the regional ITS architecture. If the final design of the ITS project is inconsistent 

with the regional ITS architecture, then the regional ITS architecture shall be 

updated as provided in the process defined in § 940.9(f) to reflect the changes.

Appendix b Regulatory Requirements

U.S. Department of Transportation

Federal Highway Administration

Federal Transit Administration

Research and Innovative Technology Administration

1200 New Jersey Avenue SE

Washington, DC 20590

Toll-Free “Help Line” 866-367-7487

www.ops.fhwa.dot.gov

Publication No.: FHWA-HOP-12-001February 2012