# Presentation: 792307

**  ****T3 Session**
**Federal Requirements for Regional ITS Architectures**

- Federal Regional ITS Architecture Requirements

**Notes:**
Title: Federal Requirements for Regional ITS Architectures

Learning Objectives:  
Participants will be able to:
Explain the Federal regulatory requirements for a regional ITS Architecture 
Discuss the implications of the upcoming April 8, 2005 deadline for regional ITS architectures
Give a high-level overview of the six recommended steps to developing a regional ITS architecture
Instructional Method: 
The instructor will briefly review the legislative history of, and US DOT policy goals for, ITS to reinforce previous sessions. The requirements laid out in the Final Rule & Policy for regional ITS architecture development will be presented and discussed
Session: Total: 75 minutes     Lecture – 60 minutes    Questions/Discussion – 15 minutes
Evaluation Plan: Participant learning will be asked to complete an on-line questionnaire at the end of the session. 
Reference Sources:
66 FR 1446 Final Rule & Policy 1/8/2001
66 FR 19854 Final Rule; Technical Correction 4/18/2001
23 CFR 940
FHWA: Regional ITS Architecture Process Seminar
US DOT National ITS Architecture Team: Regional ITS Architecture Guidance – Developing, Using, and Maintaining an ITS Architecture for your Region 10/2001

## Your Session Leaders

**HOST: Mac Lister**
**ITS Specialist**
**Operations Technical Service Team**
**FHWA Resource Center **
**(Olympia Fields, IL)**
**PRESENTER: Pamela Kordenbrock**
**Architecture Implementation Program Manager**
**Office of Transportation Management**
**FHWA Office of Operations **
**(Washington, DC)**
** **

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:

Suggested Comments:

## Session Learning Objectives

**You will be able to:**
- Explain the Federal regulatory requirements for a regional ITS Architecture
- Discuss the implications of the upcoming   April 8, 2005 deadline for regional ITS architectures
- Give a high-level overview of the recommended six-step process for developing a regional ITS architecture

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The purpose of today’s T3 session is to give you an overview of the key federal requirements concerning the development and maintenance of regional ITS Architectures.

Suggested Comments:
[Review session learning objectives]

## US DOT’s Broad Policy Goals For ITS

- Foster **integration** of Intelligent Transportation Systems
- Provide for future **interoperability** of key ITS services at a national level
**Engage** a wide range of stakeholders
**Facilitate** cost-effective ITS expansion
**Enable electronic information sharing**

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The  boldfaced words are at the heart of the US DOT’s goals for ITS.

Suggested Comments:
Integration is essential: The systems of different agencies in a larger system must be able to communicate data with one another in real time. 
Interoperability: Ensuring that different types of devices or software to work together requires the development and acceptance of common standards.
Broad stakeholder involvement is key to identifying needs that ITS can address, and in agreeing upon priorities for deployment.
Cost-effectiveness is self-explanatory.
Electronic information sharing can involve real-time information to improve system operations, and archived data to support transportation management Improvements over time.

## Background: FHWA Rule/FTA Policy

- US DOT issued interim guidance in October 1998 on consistency with the National ITS Architecture
- FTA and FHWA worked together to establish **common policies on ITS architecture conformity**

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The FHWA Rule and FTA Policy are consistent with one another. 

Suggested Comments:
Significant work went into federal ITS policy, starting with Secretary Pena’s national goal to build an ITS infrastructure in the 75 largest metropolitan areas in the US. After that charge, it was clear that ITS be indeed being deployed, but it was being inhibited by the lack of system integration, and the use of proprietary interfaces. 
Early in 1998, National ITS Architecture consistency was discussed to ensure integration. It was recognized that several ITS projects that used the National ITS Architecture were yielding significant benefits by fostering good practices. In October 1998, US DOT issued interim guidance that focused on recommendations at the planning level and the ITS project level. 
At the planning level, the interim guidance stated that statewide and metropolitan planning activities should include consideration of the development of a regional ITS architecture, and implementation and integration of ITS services. 
Once outreach was conducted and comments were received on the interim guidance, FHWA and FTA worked together to formulate common policies on architecture conformity. This led to the Final Rule and Policy.

## Federal ITS Requirements

**FR January 2001 as Final FHWA Rule and Final FTA Policy:**
- 23 CFR 940.5 (Policy)
- 23 CFR 940.7 (Applicability)
- 23 CFR 940.9 (Regional ITS architecture)
- 23 CFR 940.11 (Project implementation)
- 23 CFR 940.13 (Project administration)
_**http://www.ops.fhwa.dot.gov/its_arch_imp/policy.htm**_

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Regulations promulgating the ITS provisions in   TEA-21 issued in January 2001 and became final that April. 

Suggested Comments:  
We’ll look at these more or less in order.
FHWA and FTA simultaneously issued their directives. Because the two agencies operate under separate sections of the US Code and have different administrative procedures, the FHWA version is referred to as a Final Rule, whereas the FTA version is the Final Policy. They say essentially the same thing. You can find the Rule and Policy on the Internet at this URL.

## 23 CFR 940.5: Policy

***“******ITS projects shall conform to the National ITS Architecture and standards...”***
***Meaning: ***
- Projects must adhere to a regional ITS architecture.
- A regional architecture is developed using the National ITS Architecture and identifies appropriate ITS standards.
***“******Development of the regional ITS architecture ******should be consistent with the transportation planning process****** for Statewide and Metropolitan Transportation Planning.”***

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The policy has two parts: project conformance, and regional architecture consistency with the larger transportation planning process.
Suggested Comments:
First, ITS projects shall conform to the National ITS Architecture and Standards in accordance with the requirements contained in 23 CFR 940.5 (Policy).
Conformance with the National ITS Architecture means:
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.
Second, development of the regional ITS architecture should be consistent with the transportation planning process for Statewide and Metropolitan Transportation Planning.  This requirement has a couple of implications:
1) Transportation planners and planning organizations need to know about and understand the role of ITS in transportation management and operations.  
2) ITS projects must compete for prioritized funding through the programming process.

## 23 CFR 940.7: Applicability

- Policy applies to **all** ITS projects funded in whole or in part with the Highway Trust Fund
- There were some grandfathered exceptions

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: All ITS projects, regardless of their size, are covered by these regulations if they are receiving highway Trust Fund monies.

Suggested Comments:
All ITS projects that are funded in whole or part with the highway trust fund or National Highway System are covered by these conditions. There are a couple of exceptions to this requirement: ITS research projects are exempt, as were upgrades to systems that existed when TEA-21 was enacted if those upgrades would be more cost-effective than bringing the system into conformity.  

## 23 CFR 940.3: ITS Project

- Any project that in whole or in part funds the acquisitions of technologies, or systems of technologies, that provide or significantly contribute to the provision of one or more ITS user services as defined the National ITS Architecture.
- A MAJOR ITS project is any ITS project that implements part of a regional ITS initiative that is multi-jurisdictional, multimodal, or otherwise affects regional integration of ITS systems.

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: OK, so what IS an ITS project? 940.3 gives the definition.

Suggested comments:
[See slide; elaborate.]

## 23 CFR 940.9 Regional Architecture 

- 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 the applicable transportation plans.
- The National ITS Architecture **shall** be used as a resource in developing the regional ITS architecture.
- The regional ITS architecture **shall** be on a scale commensurate with ITS investment in the region.
- The regional ITS architecture **shall** be maintained as regional needs evolve.

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  940.9 elaborates key principles for regional ITS architectures.

Suggested Comments:
Regional ITS architectures derive their structure from the National ITS Architecture.
Remember that the planning for, and funding of, Intelligent Transportation Systems occurs within the larger framework of the statewide and metropolitan transportation planning processes. Consequently, plans for ITS need to be in synch with, and reflected in, the statewide and metro long-range plans, the STIP, and the TIPs.
Regarding the matter of scale: It’s intuitively reasonable that a modest regional investment in ITS can be captured in a relatively modest regional ITS architecture.
The regional ITS architecture should be a living document that is modified to reflect changing needs and the use of newly emerging technologies.

## What Is a Regional ITS Architecture?

- A regional framework for ensuring **institutional agreement** _and _**technical integration** for the implementation of ITS projects, or groups of projects

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The concept of regional ITS architectures arises from the understanding that current ITS systems both create opportunities for, and set limitations on, future system deployments.

Suggested Comments:
The Regional ITS Architecture serves to broaden the scope of transportation systems operations. In the past, transportation agencies focused on the implementation and operations of single technology components. The ITS architecture moves this focus to the implementation and operations of a complete, regional system. A regional architecture is a common framework that guides practitioners in establishing ITS interoperability, and helps them to choose the most appropriate strategies for processing transportation information. 

Let’s take a closer look at the definition. Why do you suppose it emphasizes both institutional agreement and technical integration? 

## Regional ITS Architecture Completion Deadlines

- If region is deploying ITS projects, must have regional ITS architecture by **April 2005**
- If no ITS projects deployed yet, regional ITS architecture must be developed **within 4 years **after its first ITS project reaches final design

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The Final Rule and Policy set deadlines for the completion of regional ITS architectures that have obvious urgency.

Suggested Comments:
So under what circumstances is a regional ITS architecture a requirement?  Well, by “deploying ITS projects,” the regulation is referring to both current and programmed investment -- that is, projects that are already happening, or projects for which funding has been assigned in the TIP and STIP. If there is only one major project underway, a project architecture must be developed; that project architecture is a proxy for the regional architecture. As more projects come into the pipeline, however, that first project architecture will become the kernel for a broader regional ITS architecture.

## 23 CFR 940.9:  A Regional Architecture Shall Contain*...

- Description of the region
- Identification of the participating agencies and stakeholders
- An operational concept that identifies the roles and responsibilities of the stakeholders
- Any agreements required for operations
**********AT A MINIMUM***

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: 23 CFR 940.9 details the eight MINIMUM COMPONENTS of a regional architecture. 
Suggested Comments:
[Walk through each without elaboration. Details will follow starting on Slide #15.]
On this and the next slide, you can see the eight MINIMUM elements that are required for inclusion in a regional ITS architecture. 
If you look at them carefully, you’ll see an emphasis on the institutional elements of the architecture -- that is, the fact that these systems are developed through the collective effort of a number -- sometimes a large number -- of participating agencies and stakeholders. 
Institutional elements require at least as much attention as  do the technical elements of the architecture.

## A Regional Architecture Shall Contain*...

- System functional requirements (high-level)
- Interface requirements and information exchanges with existing and planned systems and subsystems
- Identification of ITS standards supporting regional and national interoperability
- Sequence of projects required for implementation
**********AT A MINIMUM***

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments:
The fifth through eighth elements address the technical considerations to be addressed by the regional architecture. 

[Walk through each without elaboration.]

Now let’s look at each of these requirements in more detail.

## 1. Description of the Region

- REGION: A geographical area that identifies the boundaries of the Regional Architecture
- Locally determined by those developing the architecture
- Based on operational needs for integration and information sharing
- Metropolitan areas should consider the boundaries of the metropolitan planning area as a minimum

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The Regional Architecture contains a description of the region, which is defined by the stakeholders based on system integration needs.

Suggested Comments: 
The region covers a geographical area, but its extent and boundaries are set on the basis of a number of practical, technical, and operational considerations. 

The guiding principle for defining the ITS region is, “What makes sense?” There should be no holes in the doughnut.

## 2. Identification of the Participating Stakeholders 

- Will vary from region to region:
- Transit operators
- Highway agencies (state, county, city)
- Metropolitan Planning Organizations (MPOs)
- Regional Councils
- Tribal governments
- Public safety (police, fire, EMS ...)
- Federal lands agencies
- State motor carrier agencies
- Private sector service providers
- Others as appropriate

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  The composition of stakeholders -- those agencies or other entities with a direct interest in the integration of transportation systems through ITS -- will vary.

Suggested Comments:
This is a non-inclusive list of entities with an interest in the planning and deployment of ITS in a given region. Incidentally, the idea of “stakeholder” is context-specific: you’ll find that the stakeholders involved in the regional architecture may overlap with, but not completely involve, the stakeholders concerned with a particular project. And the project-level stakeholders may also vary, depending upon whether the discussion is about broad planning or technical specifics. So be alert to the question of who is involved: You should be asking, “What about so-and-so?”

## 3. Operational Concept

***A “big picture” view of the:***
**Goals, objectives, and desired capabilities** **of **_**each system**_** **(existing or planned) in a region, without indicating how the systems will or can be implemented
***AND***
**Roles and responsibilities** **of **_**participating agencies and stakeholders**_  in the implementation and operation of the systems included in the Regional ITS Architecture

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The operational concept for a system is a high-level, “big picture” view of how it should function, in terms of goals, objectives, and capabilities, with roles and responsibilities defined for participating agencies and stakeholders.

Suggested Comments: 
The operational concept is a TEXT document -- it does NOT focus on technology.  While the operational concept is at a high level, it can be still be defined in a systematic, explicit way. When the operational concept describes participant roles and responsibilities, look for explicit verbs like “operate,” “procure,” “maintain”, “install,” and so forth. 

## 4. Agreements Required for Operations

- Any agreements, existing or new, required for operations, including – at a minimum – those affecting:
- ITS project interoperability
- Utilization of ITS-related standards
- Operation of the projects identified in the Regional ITS Architecture
- Formality and level of detail are at stakeholder discretion

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: A list of agreements governing roles and responsibilities must be included in the Regional Architecture.

Suggested Comments: 
The region satisfies this requirement by inserting a LIST of agreements -- not the completed agreements themselves. 
Depending on the scope of the ITS projects and the nature of the region, some agreements may be relatively informal.  While more than a handshake, the level of detail beyond that is up to the stakeholders. However, where “control of” language is involved, a more formal agreement is probably needed.

## 5. System Functional Requirements 

- High-level functions, tasks, activities, or services to be performed by systems to address the needs or problems of the region
- Stakeholders define level of detail

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Use the National ITS Architecture structure and logic to define the functional requirements for regional systems. 

Suggested Comments: 
In the regional architecture document, this information is likely to be expressed diagrammatically. Many regional ITS architecture teams find that this requirement is an area for which it needs to hire consultant help.

## 6. Interface Requirements and Information Exchanges

- Identifies the types of information to be exchanged between systems and subsystems (planned and existing)
- Needs to be tailored for the region

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The regional architecture must identify what information is to be exchanged, between whom, and how.

Suggested Comments: 
A description of the interface requirements and information exchanges lends itself to interconnect diagramming. This can be kept simple and at a high level. Flows can be selected from the National Architecture.

## 7. Identification of ITS Standards

- The Rule/Policy states that ITS projects shall use ITS standards adopted by US DOT as appropriate
- A standard is _not_ required unless it is adopted through US DOT rulemaking
- Level of detail should be similar to that of the subsystems and architecture flows in the National ITS Architecture

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments: 
It’s important to understand what  is acceptable and, in fact, desirable with respect to the use of ITS standards. [Review bullets.]
US DOT prefers to expand the use of standards by providing state agencies with high-quality, open standards, combined with technical assistance programs that support efforts to use ITS standards. 

## 8. Sequence of Projects

- The scheduling of projects necessary to implement the Regional Architecture
- Recognizes that in order to initiate some projects, other projects may have to be completed first
- Understanding project sequencing helps stakeholders...
- Visualize how the region’s ITS projects will fit together over time
- Visualize their interdependencies

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The region needs to set project priorities, and identify the sequence of activities needed to implement the regional ITS architecture.

Suggested Comments:
Visualizing the sequence of events and their dependencies is at the heart of good ITS strategic planning. To get to the point of being able to schedule projects within the regional architecture, considerable work has to be done first to identify the projects, assess the feasibility of each, including funding issues, and consider their sequencing.

## Maintaining The Regional ITS Architecture

**	****A Living Document: **
*   **Agencies and stakeholders participating in the development of the Regional Architecture shall develop and implement procedures and responsibilities for maintaining it, as needs evolve within the region.  *
*	**	**	**	**	**	*23 CFR 940.9(f)

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The Regional ITS Architecture is a living document that should be revised as regional needs and systems integration evolve, and experience with systems leads to the desire to improve them. 

Suggested Comments:
In addition to the eight required items in a regional ITS architecture, 23 CFR 940.9(f) also spells out a requirement for maintaining the architecture. (This should have been listed as Requirement #9! It’s easily overlooked.) 

Maintaining the regional ITS architecture is a significant responsibility. The funding to assure the resources needed for this purpose should be explicitly built into the TIP and STIP. 

## The Regional Architecture and Transportation Planning

-    *Development of the regional ITS architecture should be consistent with the transportation planning process for Statewide and Metropolitan Transportation Planning.*
- 						23 CFR 940.5

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: And one more time, remember: ...

**23 CFR 940.11: **
**Project Implementation**

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Let’s turn now to the requirements governing project implementation.

## 23 CFR 940.11Project Implementation: Provisions

- (a) Use of systems engineering analysis
- (b) SE analysis on a scale commensurate  with project scope
- (c) SE analysis elements (minimum)
- (d) Final project design accommodation of interfaces/info exchanges specified in regional architecture

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  The Rule & Policy stipulates seven requirements for project implementation.

Suggested Comments:
In overview, these are ... [review this and next slide. DO NOT ELABORATE.]

## 23 CFR 940.11Project Implementation: Provisions

- (e) Conditions requiring development of project architecture
- (f) Use of standards when adopted
- (g) Exemption: Projects in final design stage by April 8, 2001

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Seven requirements...

Suggested Comments:
[complete review of list.]
Let’s take a closer look at these.

## Project Implementation23 CFR 940.11(a-c)

**“****All ITS projects funded with highway trust funds shall be based on a systems engineering analysis ... commensurate with the project scope.”**
**Does not apply to:**
- Research projects
- Projects in existence before TEA-21
- O&M on projects existing before 6/9/98
** **

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments:
Review slide.
All right, but what is this systems engineering analysis?

## 23 CFR 940.11(a-c)What is “a Systems Engineering Analysis”?

**A structured process for arriving at a final system design**
- Considers the total project life cycle
- Final design is selected from a range of alternatives that accomplish same objectives
- Considers both technical merits and the costs and relative value of the alternatives

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  See slide.

Suggested Comments: 
[Review slide.]

## 23 CFR 940.11(c)SE Analysis Requirements

**At a ****MINIMUM****, the SE analysis shall include seven elements:**
- 1. What part of the regional architecture is being implemented
- 2. Participating agencies and their responsibilities
- 3. Definition of systems requirements

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments:
[Review each point.]

## 23 CFR 940.11(c)SE Analysis Requirements

- 4. Analysis of alternative system configurations and tech options to meet the requirements
- 5. Procurement options
- 6. Identification of project-applicable standards and testing procedures
- 7. Procedures and resources needed for operations and management of the system

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments:
[Review each point.]

## How the Final Rule Relates to Systems Engineering

- Requirements definition
- Alternatives analysis
- Procurement options
- Standards
- Operations and maintenance

- Concept
- of Operations

- High Level
- Requirements

- Detailed
- Requirements

- High Level
- Design

- Detailed
- Design

- Regional ITS Architecture Mapping

**How the Final Rule Relates to Systems Engineering**

_**23 CFR 940.11**_

_**c.1**_

_**c.2**_

_**c.3**_

_**c.4**_

_**c.5**_

_**c.6**_

_**c.7**_

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: This diagram shows  how a Regional Architecture  maps to the systems engineering process.  The c1, c2..... C6 are the parts of the Rule/Policy.

Suggested Comments:
The Rule/Policy requires the identification of the pieces of the ITS project being implemented.  This would be performed during an assessment phase that precedes the process and should be included as part of the concept of operations.
Only the left side of the “V” diagram has been preserved, since the Rule/Policy pertains to system definition and design.
Procurement options are determined early in the project – at about the same time as the concept of operations.  They are a valid part of the systems engineering process.  
This is the time to initiate and if possible secure a funding mechanism for the project.
The concept of operations then initiates development of high-level or functional requirements.   
The reference to standards includes the selection of the standards to be used in the system. This is obviously a design activity.
The ‘testing’ mentioned in 940.11 c.6 is the development of test plans to be used as guidance during the system development.  The words are not spelled out in this figure for the sake of brevity.
Similarly, operations and maintenance refers to the development of operations and maintenance plans.  These activities must be a key element of the design and must occur prior to system implementation. 

## 23 CFR 940.11(a-c)Systems Engineering Life Cycle

**Assessment**

- Definition
- and
- Decomposition

- Time

- Integration,
- Verification,
- and
- Validation

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  This diagram, known as the “Vee” diagram, represents the systems engineering process.

Suggested Comments:
The purpose of showing you this now is largely for recognition. We’ll be examining the steps in the process in detail later. Note the key themes:
Definition
Decomposition
Integration 
Verification
Validation
Assessment
NOTE: point out completion of detailed design. Remind participants that if a region hasn’t implemented ITS previously or developed a regional architecture, they’ll need to have the latter by the time the first project gets to this point. 

## 23 CFR 940.11(a-c)Why Use Systems Engineering?

- Design and implementation of ITS projects requires consistency, orderliness, and discipline
- SE ensures the development of a system that reflects the needs of stakeholders and users
- Leads to improved system reliability and stability
- Improves the chances of developing a system on time and within budget

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  Planning and implementing ITS projects is different in many ways from conventional transportation project effort, and requires a different approach.

Suggested Comments:
[see slide.]

## Project Implementation23 CFR 940.11(d)

**“****Upon completion of the regional ITS architecture ... 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.”*******
***HOWEVER:***
** ****If the final ITS project design is inconsistent with the regional architecture, *****the regional architecture should be updated.***
****Exception: Projects that had advanced to final design by April 8, 2001***

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  See slide.

Suggested Comments:
Depending on funding levels, updates can include expanding or contracting the project scope to meet the specifications defined in the regional ITS architecture.

## Project Implementation23 CFR 940.11(f)

**“****All ITS projects funded with highway trust funds********* shall use applicable ITS standards and interoperability tests that have been officially adopted through rulemaking by the DOT.”**** **
***including transit projects**

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: See slide.

Suggested Comments:
 Remember, this means WHEN adopted.

## 23 CFR 940.13: Project Administration

**“****Prior to authorization of highway trust funds for construction or implementation of ITS projects, compliance with §940.11 shall be demonstrated.”**
**Federal-aid oversight monitoring**

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  See slide.

Suggested Comments:
Compliance with Part 940 will be monitored by the FHWA Division Offices and FTA Regional Offices under Federal-aid oversight procedures as provided under 23USC106 and 133.

[Transition to next section: the 6 steps to regional architecture development.]

## Recommended Process for Regional ITS Architecture Development

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Now let’s look at the six steps recommended for the development of a regional ITS architecture.

## Relation of the Regional Architecture Process to the Architecture Rule & Policy

**The process (and suggested outputs): **
- Address all requirements for Regional ITS Architectures in the Rule & Policy
*Do not guarantee compliance* with the Rule & Policy

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The process contained in federal guidance addresses all of the requirements for the Rule and Policy.

Suggested Comments:
The point of assuring that regions involved in ITS have a well-thought out regional architecture isn’t to check the “Yep” box for regulatory compliance. Having the regional architecture in place means that region has worked intensively and collaboratively to think through its needs and how to meet them, now and in the future.

Just completing each step doesn’t guarantee compliance.  Keep your FHWA Division and FTA Regional staff involved during development.  That way neither they nor you will have any surprises at the end.

## Regional Architecture DevelopmentStep #1: Get Started

- Regional Architecture Development**Step #1: Get Started**

**Identify Stakeholders**
- That own or operate ITS systems and other agencies that have an interest in regional transportation issues
**Identify ITS Champion(s)**
- To lead and manage architecture development effort

**Identify Need**
-  ITS projects planned?
**Define Region**
-  Geographic boundary, timeframe, and scope of services

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: Defining region and stakeholders is key to getting started, but  having a Champion is essential.

Suggested Comments:
[Stick to the slide.]
Need:  Do you have to have a regional ITS architecture now?  Do you see the value anyway? 
Region: Clear definition of region is important.
Stakeholders:  A Regional ITS Architecture is a consensus architecture.  Key: To identify who the stakeholders are and include them in the development process.
Development effort needs leader(s): We call them “champion(s).”

## Regional Architecture DevelopmentStep #2: Gather Data

**Develop Operational Concepts **
- Roles and Responsibilities
**Define Functional Requirements**
- Primary (high-level) functions of the ITS systems

**Inventory ITS Systems**
- Existing and planned ITS systems
**Determine Needs and Services **
- That ITS systems will provide

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  In order to develop a Regional ITS architecture you need to gather data about the systems in the region and the services that you want to provide with ITS.
Suggested Comments:
[Stick to the slide and save elaboration for the later sessions.]
Given the timeframe for your region (how many years into the future),  what are the ITS systems that exist now or might be developed in that timeframe?
What transportation needs (or transportation problems) does the region  have, and what services are provided, or will be provided, to address the identified needs? (E.g., Incident Management is a service most regions will be providing.)
What roles and responsibilities do your stakeholders have for providing the services?  (E.g., who is involved in incident management and what is their role?) 
Functional Requirements: These relate to the ITS systems in your inventory.

## Regional Architecture DevelopmentStep #3: Define Interfaces

**Identify Interconnects**
- Which subsystems, or subsystems and terminators, will talk to each other?
**Define Architecture Flows**
- What types of information will they share?

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  Defining interfaces means identifying interconnections and architecture flows.

Suggested Comments:
[Stick to the slide and save elaboration for the later sessions.]
“Defining interfaces” means:
Identify system interconnections:  Figure shows an example of the interconnects to the State Highway Patrol system.   You could take each element of a regional ITS architecture and create an interconnect diagram like this with the element in the center and showing all the elements that connect to it.
Identify architecture flows: What type of information is shared on the interconnect?

## Regional Architecture DevelopmentStep #4: Get Ready to Implement

- Regional Architecture Development**Step #4: Get Ready to Implement**

**Define Project Sequencing**
- Evaluate projects
- Identify project dependencies
**Develop List of Agency Agreements**
- Consider existing agreements
- Identify where new ones are needed (and type of agreement)
**Identify ITS Standards**
- Based on interconnects and information flows chosen
- Identify regional standards in use

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  Several aspects of the Regional Architecture relate to project implementation.
Suggested Comments:
Project Sequencing: The goal of the Regional ITS Architecture is to create a framework for your region’s ITS that you can use to plan your projects.  To support the prioritization of projects, one of the outputs is project sequencing.  Identify projects and their dependencies (i.e., must one be done before another one starts?).
Agency Agreements: Can take a long time.  Key is to identify early what agreements are needed so that the team can start working on them. As part of this process only a LIST of agreements is needed.  Don’t forget to look at existing agreements.
Standards:  One of the key goals of architecture development is to identify regional standards.  The team can get a detailed list of standards based on the information flows chosen.  There may also be regional standards in use -- the team should identify these for use as appropriate.

## Regional Architecture DevelopmentStep #5: Use the Regional ITS Architecture

**In the Transportation Planning Process**
- Regional Transportation Plan
- Transportation Improvement
- 	Program (TIP)
- State Transportation
- 	Improvement Program (STIP)
- ITS Strategic Plan
**To Support Project Implementation**
- Project definition
- Request for Proposal (RFP)
- 	generation
- Project implementation

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  Two key areas of use: Planning and Project Implementation.

Suggested Comments:
[Stick to the slide.]
A Regional ITS Architecture is a planning tool -- use it to support development of your transportation planning products.  It is a subset of an “ITS Strategic Plan”, which may also consider technology and institutional deployment issues.    

Regional ITS Architectures can support project implement from the early definition phase (just what is the project)  through initial stages of implementation (specifications).  

:

## Regional Architecture DevelopmentStep #6: Maintain the Regional ITS Architecture

- Regional Architecture Development**Step #6: Maintain the Regional ITS Architecture**

**Architecture is a “living” document**
- Need to update periodically
**Aspects of Maintaining the Regional ITS Architecture**
- Determine who will be responsible
- Define the architecture baseline
- Define the change management process
- Document all in a Maintenance Plan

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:  The team needs to develop a plan for maintaining the Regional ITS Architecture.  As a planning tool it must evolve as your planning horizon moves.  

Suggested Comments:
[Stick to the slide.]
Having a Maintenance Plan is one of the Requirements of the Rule/Policy.
How often should the architecture be updated?  Depends on how it is used.  For example, it could be tied to the TIP update cycle or RTP update cycle.  
Aspects of maintenance: 
Who?: Usually the organization of the regional architecture Champion.  
What?: Which documents/ databases will you maintain? 
How?: How are changes managed? Who can suggest changes? 

## Regional ITS Architecture Outputs

**Regional ITS Architecture Outputs**

**What may a Regional **
**ITS Architecture **
**look like?**
- Document(s)
- Diagrams
- Database(s)
- CD-ROM
- Web Pages
- Turbo Architecture database

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: The Regional Architecture “document” can actually take a number of forms.

Suggested Comments:
See slide.

[WIND UP CONTENT NOW. NEXT SLIDE STARTS INFO/TRAINING.]

## Information

**ITS Architecture Implementation Program:**
- _http://www.ops.fhwa.dot.gov/its_arch_imp/index.htm_
- Guidance and White Papers
- Sample Documents
- Training
- Contact Names and Numbers
**Regional ITS Architecture Guidance Document (Oct 2001):  **
- _www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE    _
-    _//13598.pdf_
**National ITS Architecture, Version 5.0:**
-  _http://www.its.dot.gov/arch/arch.htm__ _
**Turbo Architecture 3.0:**
- _http://mctrans.ce.ufl.edu/featured/turbo/_

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: There’s a lot of information available to support you in development of a regional ITS Architecture.

## Training

**FHWA:** *Regional ITS Architecture Process Seminar (1-day)*
**FHWA:** *Regional ITS Architecture Process Seminar (2-day)*
**NHI:*** Deploying the National ITS Architecture*
**NHI:*** Turbo Architecture Software Training*
**NTI:*** **Complying with Federal Transit Administration's Policy on ITS Architecture Consistency*

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message: A number of training opportunities are also available from a variety of sources.

## Review: Session Learning Objectives 

- Explain the Federal regulatory requirements for a regional ITS Architecture
- Discuss the implications of the upcoming   April 8, 2005 deadline for regional ITS architectures
- Give a high-level overview of the recommended six-step process for developing a regional ITS architecture

- Federal Regional ITS Architecture Requirements

**Notes:**
Key Message:

Suggested Comments: