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 objectives-driven, 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, performance-based 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. What M&O strategies (supported by ITS) may be available to help achieve our operations objectives? What data is available in the region to monitor transportation system performance and track progress toward operations objectives? What are the gaps in providing transportation system management and operations across our region? 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? 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.

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

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.

3.2. Developing Goals, Operations Objectives, and Performance Measures

The initial step in the objectives-driven, performance-based 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:

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

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 Architecture¹⁵ 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 high-level 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.

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.

Figure 15. Minnesota Statewide Transportation Plan to Architecture Mapping

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.

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."¹⁶ 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." ¹⁷ 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.

Addresses Core Question: What data is available in the region to monitor transportation system performance and track progress toward operations objectives?

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.¹⁸ 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.

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

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.

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.

Addresses Core Question: What are the gaps in providing transportation system management and operations across our region?

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.²⁰ 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.

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

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

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

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 may not have been selected with the regional operations objectives in mind, they will need to be evaluated for relevance. The Turbo Architecture Planning Tab²¹ 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.

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.

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

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.

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?

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

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.

Figure 19: Using Service Package Customization to Define Projects in the Maricopa Association of Governments Regional ITS Architecture.

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."

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

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.

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.²⁵ 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."²⁶ 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.

Figure 20: Excerpt from Project Proposal Template in the 2009 Virginia DOT's Northern Virginia Operations Planning Guide: Leveraging ITS Architecture and Systems Engineering.

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

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 https://ops.fhwa.dot.gov/int_its_deployment/sys_eng.htm for additional information and resources including the Systems Engineering Handbook (https://ops.fhwa.dot.gov/publications/seitsguide/index.htm) and Systems Engineering Guidebook (https://www.fhwa.dot.gov/cadiv/segb/).

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.

Addresses Core Question: How can we define an M&O project or program in terms of functional requirements, operations concepts, supporting ITS standards, etc.?

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.

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.²⁸ 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 Architecture²⁹ to quickly assemble the pieces of the regional ITS architecture that apply to the initial ATM project into an ATM project architecture.

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

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.

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.

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: ops.fhwa.dot.gov/1201/.

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

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.