ITS Transit Standards Professional Capacity Building Program

Module 1: Introduction to Intelligent Transportation Systems (ITS) Transit Standards

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Module 1: Introduction to Intelligent Transportation Systems Transit Standards

Table of Contents

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 5

Glossary - 15

References - 15

Study Questions - 16

Module Description

This introductory Module provides an overview of Intelligent Transportation Systems (ITS) Standards for practicing transit professionals and decision makers who are engaged in the deployment of ITS for transit.

1. Introduction/Purpose

This Module will highlight the program and organizational benefits, costs of the adaptation, and use of ITS Standards to support the deployment of interoperable systems. This module will also introduce the Systems Engineering Process (SEP) and articulate benefits of using SEP for ITS transit projects. Finally, the module will summarize and provide the context for the more detailed subsequent modules of transit standards training, and provide the audience with a useful roadmap of other standards modules they might want to view. As such, this module serves as a useful prerequisite for Modules 2 through 11, and is also recommended for senior transit management due to its review of benefits and costs, which are key issues related to the implementation of ITS standards for transit.

2. Samples/Examples

The Context Diagram from the Data Exchange Format Specification (DXFS) shown in part on slide 17 is shown below:

(Extended Text Description: A graphic showing the interfaces to transit agency systems described as part of the Real-time System Management Information Program (RTSMIP). The diagram is taken from the Data Exchange Format Specification (DXFS) document. The image shows a series of interconnected boxes. The key at the bottom shows a black line and arrow labeled "Interfaces that will be the subject of the DXFS." A dotted blue line and arrow is labeled "Additional interfaces discussed in ConOps." The first box on the left reads "Private Data Collection Organization Systems" which is connected by a blue dotted arrow to "Transportation Agency Systems" and by another blue dotted arrow to "Transit Agency Systems." "Transportation Agency Systems" is then connected via a bi-directional black arrow to "Transit Agency Systems." Both of those boxes are then connected by black arrows to "Public Traveler Information Provider Systems" and "Private Third Party Provider Systems." "Public Traveler Information Provider Systems" is also connected via a black arrow to "Private Third Party Provider Systems." "Transportation Agency Systems" is connected by black bidirectional arrows to three boxes above it: "Peer Transportation Agency Systems," "Public Safety Agency Systems" and "Other Public Agency Systems." "Transportation Agency Systems," "Public Traveler Information Provider Systems" and "Private Third Party Provider Systems" are connected by dotted blue arrows to a box on the right labeled "Travelers.")

The Systems Engineering Vee diagram shown on slide 30 is shown below:

(Extended Text Description: A graphic of the Vee Diagram, which shows the life cycle of an ITS system. The Vee Diagram shows the steps in the Systems Engineering Process. These steps are: Regional ITS Architecture, Concept Exploration, Systems Engineering Management Plan Framework, Concept of Operations, System Requirements, Subsystem Requirements/ Project Architecture, Component Level (Detailed Design), Software Coding/ Hardware Fabrication, Unit Testing, Subsystem Integration & Testing, System Integration & Verification, System Validation, Operation & Maintenance, Changes & Upgrades, Retirement/ Replacement. The diagram also shows the connection between the left and right sides of the Vee. The left side of the Vee shows an arrow pointing down along the Vee labeled Decomposition and Definition. The bottom of the Vee show an arrow pointing left to right labeled Life Cycle Time Line. On the symmetrical opposite side going up the Vee is another arrow labeled Integration and Recomposition. In between each step is a Decision Milestone. Connecting the left side of the Vee to the right side of the Vee are various bidirectional arrows: Concept of Operations is connected via System Validation Strategy/Plan to System Validation. System Requirements is connected via System Verification Plan (System Acceptance) to System Integration & Verification. Subsystem Requirements Project Arch is connected via Subsystem Verification Plan (Verify Subsystems) to Subsystem Integration & Verification. Finally, Component Level Design is connected via Unit Testing Plan to Unit Testing.)

The comparison of the SEP with the traditional project development process shown on slide 32 is below:

(Extended Text Description: This image shows the same Vee Diagram as shown and described previously, with an additional top graphic that runs horizontal across the Vee diagram, showing the traditional project development cycle with the following steps, in order: Transportation Planning, Programming/Budgeting, Project Initiation, Preliminary Engineering, Plans Specs & Estimates, Implementation, Project Closeout, Operations & Maintenance, Changes & Upgrades, and Retirement/ Replacement. The bottom portion of the diagram is the same Vee along with lines showing the connections between the two processes. Project Initiation connects with Systems Engineering Management Plan Framework, Preliminary Engineering covers from the previous point to the decision milestone after System Requirements, Plans Specs & Estimates covers from the previous point to the decision milestone after Component Level Design, and Implementation covers from the previous point to the decision milestone after System Validation.)

Example regions from actual Regional ITS Architectures shown on Slide 35 are below. The regions are Mesilla Valley MPO (New Mexico), Florida DOT District 7, and West Virginia (an example of a "statewide" ITS architecture).

(Extended Text Description: For illustration purposes only: There are three graphics on the page showing examples of types of "Regions" used to create regional ITS architectures. The left diagram is of Mesilla Valley Metropolitan Planning Organization, the middle diagram is of Florida DOT District 7, and the right diagram is of the state of West Virginia.)

The top level interconnect diagram from the National ITS Architecture, from slide 36, is shown below:

(Extended Text Description: Graphic of the "Sausage Diagram" diagram of the National ITS Architecture, which shows a high level interconnect diagram of the 22 subsystems of the National ITS Architecture. The diagram is divided into four main sections, with a series of connecting communications formats. In the upper left corner, the Travelers section (yellow background) has two sub-boxes within it: Remote Traveler Support (top, connected by a line to Fixed Point – Fixed Point Communications) and Personal Information Access (bottom, connected by a line to Wide Area Wireless (Mobile) Communications underneath and Fixed Point – Fixed Point Communications underneath and to the right). At the top right, the larger Centers section (green background) has two rows of sub-boxes within it. Top row, left to right: Traffic Management, Emergency Management, Payment Administration, Commercial Vehicle Administration, and Maintenance & Construction Management. Bottom row, left to right: Information Service Provider, Emissions Management, Transit Management, Fleet and Freight Management, and Archived Data Management. Every one of these sub-boxes under Centers is connected by a line to the Fixed Point – Fixed Point Communications box underneath the Centers section and to the right of the Wide Area Wireless (Mobile) Communications box (under Travelers section). To the lower left there is a Vehicles section (blue background) with a set of diagonally ascending sub-boxes within it (start lower left to the upper right of the box): Maintenance & Construction Vehicle, Transit Vehicle, Commercial Vehicle, Emergency Vehicle, and Vehicle. Each of these sub-boxes is connected by a line to the Wide Area Wireless (Mobile) Communications box above it, and to the vertically-running Vehicle-Vehicle Communications box to the left of the Vehicles section. To the lower right, there is a Field section (orange background) with a set of diagonally descending sub-boxes within it (from upper left to lower right): Roadway, Security Monitoring, Roadway Payment, Parking Management, and Commercial Vehicle Check. Each sub-box is connected by a line to the Fixed Point – Fixed Point Communications box above it, and to the vertically-running Field – Vehicle Communications box to the left (in between the Vehicles and Field sections). See Author Notes below for more information.)

The shaded area of the diagram below, from slide 37, shows where standards fit into the SEP.

(Extended Text Description: Graphic shows the left side of the Vee diagram as described above with a shaded oval showing the two steps in the process where standards are defined and tailored. The two areas that are highlighted include High-Level Design Subsystem Requirements and Detailed Design.)

3. Reference to Other Standards

Two FHWA Rules (one of which is also an FTA Policy) are referenced in the module. They are provided below:

3.1 FTA Policy on Architecture and Standards

Federal Register Vol. 66, No. 5/Monday, January 8, 2001 / Notices

DEPARTMENT OF TRANSPORTATION

Federal Transit Administration

Federal Transit Administration National ITS Architecture Policy on Transit Projects

AGENCY: Federal Transit Administration (FTA), DOT.

ACTION: Notice.

SUMMARY: The Federal Transit Administration (FTA) announces the FTA National ITS Architecture Policy on Transit Projects, which is defined in this document. The National ITS Architecture Policy is a product of statutory changes made by the Transportation Equity Act for the 21st Century (TEA-21) (Pub. L. 105-178) enacted on June 9, 1998. The National ITS Architecture Policy is also a product of the Request for Comment on the National ITS Architecture Consistency Policy for Project Development that was published in The Federal Register on May 25, 2000. Because it is highly unlikely that the entire National ITS Architecture would be fully implemented by any single metropolitan area or State, this policy requires that the National ITS Architecture be used to develop a local implementation of the National ITS Architecture, which is referred to as a "regional ITS architecture." Therefore, conformance with the National ITS Architecture is defined under this policy as development of a regional ITS architecture within four years after the first ITS project advancing to final design, and the subsequent adherence of ITS projects to the regional ITS architecture. The regional ITS architecture is based on the National ITS Architecture and consists of several parts including the system functional requirements and information exchanges with planned and existing systems and subsystems and identification of applicable standards, and would be tailored to address the local situation, and ITS investment needs.

DATE: Effective Date: This policy is effective from February 7, 2001.

ADRESSES: For FTA staff, Federal Transit Administration, Department of Transportation (DOT), 400 Seventh Street, SW., Washington, DC 20590.

FOR FURTHER INFORMATION CONTACT: For Technical Information: Ron Boenau, Chief. Advanced Public Transportation Systems Division (TRI-11), at (202) 366-0195 or Brian Cronin, Advanced Public Transportation Systems Division (TRI-11), at (202) 366-8841. For Legal Information: Richard Wong, Office of the Chief Council (202) 366-1936. The policy is posted on the FTA website on the Internet under https://www.transit.dot.gov/sites/fta.dot.gov/files/FTA_ITS_Policy.pdf.

Electronic Access: An electronic copy of this document may be downloaded using a computer, modem and suitable communications software rom the Government Printing Office's Electronic Bulletin Board Service at (202) 512-1661. Internet users may reach the Office of the Federal Register's home page at: https://www.ofr.gov/ - content is no longer available and the Government Printing Office's web page at: https://www.gpo.gov/.

Internet users may access all comments received by the U.S. DOT Dockets, Room PL-401, for the Request for Comment that was issued on May 25, 2000 which were used to clarify this Policy, by using the universal resource locator (URL): https://www.regulations.gov/. It is available 24 hours each day, 365 days each year. Please follow the instructions online for more information and help. The docket number for the Request for Comment was FTA-99-6417.

SUPPLEMENTARY INFORMATION

I. Background

The Federal Transit Administration (FTA) published a Request for Comment on May 25, 2000, to implement section 5206(e) of the Transportation Equity Act for the 21st Century (TEA-21) (Published 105-178), which was enacted on June 9, 1998.

Section 5206(e) of TEA-21 requires that the Secretary of the DOT must

Ensure that intelligent transportation system projects carried out using funds made available from the Highway Trust Fund., * * * conform to the national architecture, applicable standards or provisional standards, and protocols developed under subsection (a).

The objectives for the FTA's National ITS Architecture Policy for Transit Projects are to:

• Provide requirements for ITS project development for projects implemented wholly or partially with highway trust funds.
• Achieve system integration of ITS projects funded through the highway trust fund with other transportation projects planned for the region, which will thereby enable electronic information and data sharing for advanced Management and operations of the ITS infrastructure.
• Engage stakeholders (state DOT's, transit agencies, public safety agencies, other transportation operating agencies) in the project development and implementation process.
• Facilitate future expansion capability of the IT's infrastructure.
• Save design time through use of the National ITS Architecture requirements definitions and market packages.

FTA has developed this policy to meet the TEA-21 requirement contained in Section 5206(e) and the DOT/FTA goal lo encourage effective development of ITS projects. Additionally, DOT and FTA encourage the coordination of local ITS strategies and projects to help meet national and local goals for mobility, accessibility, safety, security, economic growth and trade, and the environment.

The National ITS Architecture documents were developed by the US DOT, and are updated on an as-needed basis. Current work to update the National ITS Architecture is the Archive Data User Service, which provides the ability to store and process data over an extended period of time. FTA is pursuing the addition of a Rail ITS program for travel management, vehicles, and users. New versions of the documents, when they are issued, will be available from the US DOT on the DOT website at www.its.dot.gov. Version 3.0 is the latest version of the National ITS Architecture.

The first section of this policy contains a complete analysis of and response to the comments provided to the docket. The remainder of the Notice contains the FTA National ITS Architecture Policy for Transit Projects.

II. Public Comments

Eighteen comments were submitted to the FTA National ITS Architecture Consistency Policy for Project Development docket by the September 23, 2000, close of the comment period. Comments wore submitted by transit operators (3), state and local governments (5), metropolitan planning organizations (4), industry associations (3), and consultants (3). As indicated earlier, a complete analysis and response to the docket comments is provided. In order to facilitate focused comments, FTA asked a series of questions about the policy. The public comments section is organized first by analysis and response to the specific questions asked; second by responses to comments not specifically related to one of the nine questions; and finally by an explanation of other changes. In general, the comments received were positive. Therefore, the FTA has kept the scope of the policy and made appropriate clarifications to the text of the policy to address concerns raised in comments. In response to the many comments requesting it, the FTA, in association with the ITS Joint Program Office, in the Federal Highway Administration (FHWA) will also provide a program of guidance, training, and technical support to assist with the implementation of this policy.

Questions

1. Do reviewers understand the definition of a major ITS investment as defined in Section IV, "Regional ITS Architecture," or is more clarification needed, and if so please explain?

Comments: Nine commenters submitted responses to this question. In general, commenters found the definition confusing, and did not understand why major ITS projects need to be called out over other ITS projects. One commenter noted that small dollar projects can have a major impact on future development, while an expensive system may have no impact. Another commenter was unclear about the term "supporting national interoperability."

Response: Of specific concern to the agency is the timing in which requirements for this policy are enacted. As such, the terms "major ITS investment" and "major ITS project" were provided so as to distinguish between projects that will require immediate correlation to the regional ITS architecture and those that do not. The term "major ITS investment" was also found to be redundant to "major ITS project" and was removed from the policy. Guidance on the classification of "ITS projects" and "major ITS projects" will be provided upon enactment of the policy.

2. Do reviewers understand the definition of an ITS project, or is more clarification needed, and if so please explain?

Comments: Nine commenters submitted responses to this question. Commenters found this term less confusing than "major ITS investments," but requested more clarification. Some commenters proposed alternative language or asked for clarification on particular examples.

Response: The agency has clarified the definition by deleting the potentially ambiguous examples provided and will develop guidance material that provides examples of projects that will be considered ITS projects and those that will not be considered ITS projects. In general, unless a technology project is implementing one of the ITS user services defined in the National ITS Architecture, it would not be considered an ITS project.

3. Do reviewers understand the difference between a "major ITS investment," and an "ITS project", or is more clarification needed, and if so please explain?

Comments: Eight commenters submitted responses to this question. Commenters had mixed responses, as some commenters found the differences to be clear, while others requested that guidance material be provided to further explain the differences. Commenters did suggest that a "project" is a "project" and should not be quantified in terms of dollar amounts.

Response: As described in the response to question 1, the agency has removed the term "major ITS investment" and will provide guidance on the term "ITS project."

4. Are the requirements for development of a Regional ITS Architecture clear? If not, what is not clear about the requirement?

Comment: Nine commenters provided responses to the question. Most commenters found the requirements to be unclear and/or did not agree with the requirements. One commenter suggested that a region will have different definitions. One commenter noted that a concept of operations and conceptual design are normally conducted at the project level. One commenter requested clarification as to the appropriate place to program projects, in the regional ITS architecture, or in the planning process.

Response: Of specific concern to the agency is providing a flexible policy that allows the transportation stakeholders to define their region and the roles and responsibilities of each stakeholder during the development of a regional ITS architecture. As such, the agency has clarified the requirements of a regional ITS architecture and also removed the specific requirements for a Concept of Operations and a Conceptual Design. Instead, the agency has listed the specific requirements for a regional ITS architecture and has left the development, documentation, and maintenance of the regional ITS architecture to the stakeholders involved. Also, the region is defined as "a geographical area that is based on local needs for sharing information and coordinating operational strategies among multiple projects." A region can be specified at a metropolitan, Statewide, multi-State, or corridor level. Additional guidance on this topic will be provided after enactment of the policy.

5. What additional guidance, if any, is required to explain how to implement this proposed policy?

Comments: Ten commenters provided responses to this question. All the comments called for additional guidance on the specifics of implementing this policy. Commenters requested guidance on the definition of a "region," the ownership of the regional ITS architecture, determination of stakeholders, regional ITS architecture maintenance, certification and simplification of definitions. One commenter requested that the policy be limited to only the ITS Integration Requirements defined in the Metropolitan and Statewide Planning NPRM.

Response: The agency will provide guidance materials to address the comments suggested. The ITS Integration Strategy, as defined in the NPRM, is part of the planning process and as such does not satisfactorily address project level requirements.

6. The proposed rule allows regions to develop a Regional Architecture as a separate activity, or incrementally, as major ITS investments are developed within a region. Do reviewers anticipate particular difficulties with implementing and documenting either approach?

Comments: Nine commenters provided responses to this question. Commenters largely did not favor one approach over the other. One commenter suggested that a regional ITS architecture with a twenty year time horizon is impractical and infeasible. One commenter suggested that either approach would require additional staff resources.

Response: The agency was concerned about the time horizon and development process needed to create a regional ITS architecture within the time period required and as a result suggested both an incremental and initial comprehensive approach. Based on the responses, the agency has modified the policy to be silent on the approach used to develop the regional ITS architecture. Instead, the agency focused on the products included in the regional ITS architecture, the effective date of the requirements, and the catalyst for requiring the development of a regional ITS architecture.

7. Do reviewers understand the relationships between the Integration Strategy, the Regional ITS Architecture, and the ITS Project Architecture?

Comment: Seven commenters provided a response to this question. In general, commenters did not understand the relationship between the Integration Strategy, regional ITS architecture, and the ITS Project Architecture. One commenter suggested that flexibility in application of project architecture must be maintained to accommodate legacy systems and to take advantage of technological innovation, while maintaining the outcome of interoperability, where applicable.

Response: The Agency is concerned with linkage between the planning process and the project development process. However, this policy only deals with the project level requirements. Planning level requirements, including the Integration Strategy, will be explained as the Metropolitan and Statewide Planning Process rulemaking process is advanced. This policy only requires that the regional ITS architecture should be consistent with the transportation planning process. A definition for a project level ITS architecture has been added to the policy.

8. What additional guidance, if any, is required regarding phasing of this rule?

Comments: Six commenters submitted responses to this question. In general, the commenters stated that the phasing was clear. However, one commenter requested a three-year phase-in period. Several commenters requested that existing projects be exempt from the policy.

Response: The agency has clarified the policy statements that refer to the project status and the applicability of this policy. Projects that have reached final design by the date of this policy are exempt from the policy requirements. The agency has extended the time period for regional ITS architecture development to four years. Any region that is currently implementing ITS projects shall have a regional architecture within four years of the effective date of the final policy. All other regions not currently implementing ITS projects shall have a regional ITS architecture in place within four years of the first ITS project for that region advancing to final design.

9. Are the oversight and documentation requirements clear? If not, what is not clear about the requirements?

Comments: Eight commenters submitted responses to this question. Commenters in general requested more guidance from FTA on oversight and documentation requirements, but few provided suggestions to clarify the requirements. One commenter suggested that checklists to verify consistency requirements will be needed. Other commenters suggested that self-certification should be allowed, but also needs to be clearly defined.

Response: The agency will continue to use normal existing oversight procedures to review grantee compliance with FTA policies and regulations. Normal oversight procedures include the annual risk assessment of grantees performed by regional office staff, triennial reviews, planning process reviews, and project management oversight reviews, as applicable. In TEA-21, FTA was granted authority to use oversight funds to provide technical assistance to grantees in which oversight activities suggested non-compliance with agency policies and regulations. FTA is using oversight funds to specifically hire contractors with ITS experience who will monitor and assist grantees who are at risk of NOT meeting the National ITS Architecture Policy requirements. Additional guidance on oversight and documentation requirements will be provided.

Additional Comments

One commenter suggested that the proposed guidance circular requires that all of the agencies in a region agree before a project can be implemented, thus conferring "veto" power over the project. The agency does not intend for the policy to halt ITS deployment in areas where agencies cannot agree on project designs. As part of the regional ITS Architecture development, the agencies can agree to disagree, however, the regional ITS architecture should include a representation of the standalone ITS deployments.

One commenter suggests that the proposal infers that existing agreements between agencies will now need to be amended or redone, which would result in a halt in operations of successful ITS projects and prevent the completion of other ITS projects. In response to the comment, the agency has clarified the regional ITS architecture requirements to specify that existing agreements that address the regional ITS architecture requirements are sufficient and that new agreements are not necessarily required.

One commenter noted that a definition of ITS was not included in the policy. The commenter suggested that the definition provided in TEA-21 section 5206(e) should be included in the policy. The agency agrees and has added the definition of ITS to the list of definitions. However, the legislative definition of ITS is broad and other commenters have suggested that if the policy is written to include every new piece of electronics or hardware, then the policy would be too limiting. As a result, the policy is intended to apply only to projects meeting the definition of an "ITS project" listed in the "Definitions" section of the policy.

One commenter suggested that DOT should ensure that the Federal Highway Administration's (FHWA's) regulation and the FTA policy have the same statutory standing and that their requirements in ITS planning and deployment be consistent if not identical. The FTA and FHWA have different processes and procedures for project development. Therefore, the FHWA has issued a regulation, and FTA has issued the policy. The policy language in each document is consistent and will be carried out in a coordinated fashion, as applicable under FTA and FHWA project management and oversight procedures. FTA and FHWA planning procedures are a joint regulation and as such will be identical.

FTA received some comments regarding the use of standards. Several comments concern the premature use of required standards and interoperability tests, their impact on legacy systems, and confusion regarding the term "adopted by the USDOT."

In response to the comments, FTA has significantly modified the final policy to eliminate reference to the use of standards and interoperability tests prior to adoption through formal rulemaking. It is not the intent of the USDOT to formally adopt any standard before the standard is mature; also, not all ITS standards should, or will, be formally adopted by the USDOT. The only interoperability tests that are currently contemplated by the USDOT are those associated with the Commercial Vehicle Operations (CVO) program. These tests are currently being used by States deploying CVO systems and will follow a similar set of criteria for adoption as those defined for standards.

Other Changes

Several commenters expressed concern about linkages to the planning rule and the integration strategy. Comments regarding the portions of the National ITS Architecture conformity process included in the proposed transportation planning rule will be addressed as that rule proceeds to its issuance. The FHWA rule and the parallel FTA policy have been developed without direct reference to the proposed changes to the transportation planning process, including no mention of the development of an integration strategy. However, the policy statement of this guidance notes a link to transportation planning processes, and fully supports those collaborative methods for establishing transportation goals and objectives.

Policy Contents

I. Purpose

II. Definitions

III. Policy

IV. Applicability

V. Regional ITS Architecture

VI. Project Implementation

VII. Project Oversight

VIII. FTA Guidance

I. Purpose

This policy provides procedures for implementing section 5206(e) of the Transportation Equity Act for the 21st Century, Public Law 105-178, 112 Stat. 547, pertaining to conformance with the National Intelligent Transportation Systems Architecture and Standards.

II. Definitions

Intelligent Transportation Systems (ITS) means electronics, communications or information processing used singly or in combination to improve the efficiency or safety of a surface transportation system.

ITS project means any project that in whole or in part funds the acquisition of technologies or systems of technologies that provide or significantly contribute to the provision of one or more ITS user services as defined in the National ITS Architecture.

Major ITS project means any ITS project that implements part of a regional ITS initiative that is multi-jurisdictional, multi-modal, or otherwise affects regional integration of ITS systems.

National ITS Architecture (also "national architecture") means a common framework for ITS interoperability. The National ITS Architecture comprises the logical architecture and physical architecture which satisfy a defined set of user services. The National ITS Architecture is maintained by U.S. DOT (Department of Transportation) and is available on the DOT web site at https://www.its.dot.gov.

Project level ITS architecture is a framework that identifies the institutional agreement and technical integration necessary to interface a major ITS project with other ITS projects and systems.

Region is the geographical area that identifies the boundaries of the regional ITS architecture and is defined by and based on the needs of the participating agencies and other stakeholders. A region can be specified at a metropolitan, Statewide, multi-State, or corridor level. In metropolitan areas, a region should be no less than the boundaries of the metropolitan planning area.

Regional ITS architecture means a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects.

Systems engineering is a structured process for arriving at a final design of a system. The final design is selected from a number of alternatives that would accomplish the same objectives and considers the total life-cycle of the project including not only the technical merits of potential solutions but also the costs and relative value of alternatives.

III. Policy

ITS projects shall conform to the National ITS Architecture and standards in accordance with the requirements contained in this part. Conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a regional ITS architecture in support of integration and the subsequent adherence of all ITS projects to that regional ITS architecture. Development of the regional ITS architecture should be consistent with the transportation planning process for Statewide and Metropolitan Transportation Planning (49 CFR part 613 and 621).

IV. Applicability

(a) All ITS projects that are funded in whole or in part with the Highway Trust Fund (including the mass transit account) are subject to these provisions.

(b) The Secretary may authorize exceptions for:

1. Projects designed to achieve specific research objectives outlined in the National ITS Program Plan under section 5205 of the Transportation Equity Act for the 21st Century or the Surface Transportation Research and Development Strategic Plan developed under section 5208 of Title 23, United States Code; or

2. The upgrade or expansion of an ITS system in existence on the date of enactment of the Transportation Equity Act for the 21st Century if the Secretary determines that the upgrade or expansion –

a. Would not adversely affect the goals or purposes of Subtitle C (Intelligent Transportation Systems) of the Transportation Equity Act for the 21st Century and

b. Is carried out before the end of the useful life of such system; and

c. Is cost-effective as compared to alternatives that would meet the conformity requirement of this rule

(c) These provisions do not apply to funds used for Operations and Maintenance of an ITS system in existence on June 9, 1998.

V. Regional ITS Architecture

(a) A regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans. The National ITS Architecture shall be used as a resource in the development of the regional ITS architecture. The regional ITS architecture shall be on a scale commensurate with the scope of ITS investment in the region. Provision should be made to include participation from the following agencies, as appropriate, in the development of the regional ITS architecture: Highway agencies; public safety agencies (e.g., police, fire, and emergency/medical); transit agencies; federal lands agencies; state motor carrier agencies; and other operating agencies necessary to fully address regional ITS integration.

(b) Any region that is currently implementing ITS projects shall have a regional ITS architecture February 7, 2005.

(c) All other regions not currently implementing ITS projects shall have a regional ITS architecture within four years of the first ITS project for that region advancing to final design.

(d) The regional ITS architecture shall include, at a minimum, the following:

(1) A description of the region;

(2) Identification of participating agencies and other stakeholders;

(3) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture;

(4) Any agreements (existing or new) required for operations, including at a minimum those affecting integration of ITS projects; interoperability of different ITS technologies, utilization of ITS-related standards, and the operation of the projects identified in the regional ITS architecture;

(5) System functional requirements;

(6) Interface requirements and information exchanges with planned and existing systems and subsystems (for example, subsystems and architecture flows as defined in the National ITS Architecture);

(7) Identification of ITS standards supporting regional and national interoperability;

(8) The sequence of projects required for implementation of the regional ITS architecture.

(e) Existing regional ITS architectures that meet all of the requirements of section V(d) shall be considered to satisfy the requirements of V(a).

(f) The agencies and other stakeholders participating in the development of the regional ITS architecture shall develop and implement procedures and responsibilities for maintaining the regional ITS architecture, as needs evolve within the region.

VI. Project Implementation

(a) All ITS projects funded with mass transit funds from the highway trust fund shall be based on a systems engineering analysis.

(b) The analysis should be on a scale commensurate with the project scope.

(c) The systems engineering analysis shall include, at a minimum:

(1) Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture).

(2) Identification of participating agencies' roles and responsibilities;

(3) Requirements definitions:

(4) Analysis of alternative system configurations and technology options to meet requirements;

(5) Analysis of financing and procurement options;

(6) Identification of applicable ITS standards and testing procedures; and

(7) Procedures and resources necessary for operations and management of the system;

(d) Upon completion of the regional ITS architecture required in section V, the final design of all ITS projects funded with highway trust funds shall accommodate the interface requirements and information exchanges as specified in the regional ITS architecture. If the final design of the ITS project is inconsistent with the regional ITS architecture, then the regional ITS architecture shall be updated as per the process defined in V(f) to reflect the changes.

(e) Prior to completion of the regional ITS architecture, any major ITS project funded with highway trust funds that advances to final design shall have a project level ITS architecture that is coordinated with the development of the regional ITS architecture. The final design of the major ITS project shall accommodate the interface requirements and information exchanges as specified in this project level ITS architecture. If the project final design is inconsistent with the project level architecture, then the project level ITS architecture shall be updated to reflect the changes. The project level ITS architecture is based on results of the systems engineering analysis, and includes the following:

(1) A description of the scope of the ITS project

(2) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the ITS project;

(3) Functional requirements of the ITS project;

(4) Interface requirements and information exchanges between the ITS project and other planned and existing systems and subsystems; and

(5) Identification of applicable ITS standards

(b) All ITS projects funded with Mass Transit Funds from the Highway Trust Funds shall use applicable ITS standards and interoperability tests that have been officially adopted through rulemaking by the United States Department of Transportation (US DOT).

(c) Any ITS project that has advanced to final design by (effective date of policy) is exempt from the requirements of VI.

VII. Project Oversight

(a) Prior to authorization of Mass Transit Funds from the Highway Trust Fund for acquisition or implementation of ITS projects, grantees shall self-certify compliance with sections V and VI. Compliance with this policy shall be monitored under normal FTA oversight procedures, to include annual risk assessments, triennial reviews, and program management oversight reviews as applicable.

(b) Compliance with the following FTA Circulars shall also be certified:

• C5010.1C, Grant Management Guidelines
• C6100.1B, Application Instructions and Program Management Guidelines

VIII. FTA Guidance

FTA will develop appropriate guidance materials regarding the National ITS Architecture Consistency Policy.

Issued on: January 2, 2001.

Nuria I. Fernandez,

Acting Administrator.

[FR Doc. 01-392 Filed 1-5-01; 8:45 am]

BILLING CODE 4910-57-P

3.2 Rule 23 CFR 511- Real Time System Management Information Program

Federal Highway Administration, DOT § 511.303

PART 511 - REAL-TIME SYSTEM MANAGEMENT INFORMATION PROGRAM

Subparts A-B [Reserved]

Subpart C - Real-Time System Management Information Program

Sec.

511.301 Purpose.

511.303 Definitions.

511.305 Policy.

511.307 Eligibility for Federal funding.

511.309 Provisions for traffic and travel conditions reporting.

511.311 Real-time information program establishment.

511.313 Metropolitan Area real-time information program supplement.

511.315 Program administration.

AUTHORITY: Section 1201, Pub. L. 109-59; 23 U.S.C. 315; 23 U.S.C. 120; 49 CFR 1.48.

SOURCE: 75 FR 68427, Nov. 8, 2010, unless otherwise noted.

Subparts A – B [Reserved]

Subpart C – Real-Time System Management Information Program

§511.301 Purpose.

The purpose of tills part Is to establish the provisions and parameters for the Real-Time System Management Information Program. These provisions Implement Subsections 1201(a)(1), (a)(2), and (c)(1) of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU) (Pub. L. 109-59; 119 Stat. 1144), pertaining to Congestion Relief.

§511.303 Definitions.

Unless otherwise specified in this part, the definitions in 23 U.S.C. 101(a) are applicable to this subpart. As used in this part:

Accuracy means the measure or degree of agreement between a data value or set of values and a source assumed to be correct.

Availability means the degree to which data values are present in the attributes (e.g., speed and travel time are attributes of traffic) that require them. Availability is typically described in terms of percentages or number of data values.

Congestion means the level at which transportation system performance is unacceptable due to excessive travel times and delays.

Data Quality means the fitness of data for all purposes that require such data.

Full construction activities mean roadway construction or maintenance activities that affect travel conditions by closing and reopening roadways or lanes.

Metropolitan areas means the geographic areas designated as Metropolitan Statistical Areas by the Office of Management and Budget in the Executive Office of the President with a population exceeding 1,000,000 inhabitants.

Real-time information program means the program by which States gather and make available the data for traffic and travel conditions. Such means may involve State-only activity (including cooperative activities engaging multiple State agencies), State partnership with commercial providers of value-added information products, or other effective means that enable the State to satisfy the provisions for traffic and travel time conditions reporting stated in this section.

Routes of significance are non-Interstate roadways in metropolitan areas that are designated by States as meriting the collection and provision of information related to traffic and travel conditions. Factors to be considered in designating routes of significance include roadway safety (e.g., crash rate, routes affected by environmental events), public safety (e.g., routes used for evacuations), economic productivity, severity and frequency of congestion, and utility of the highway to serve as a diversion route for congestion locations. All public roadways including arterial highways, toll facilities and other facilities that apply end user pricing mechanisms shall be considered when designating routes of significance. In identifying these routes, States shall apply the collaborative practices and procedures that are used for compliance with 23 CFR part 940 and 23 CFR part 420.

§511.305 23 CFR Ch. I (4-1-11 Edition)

Statewide incident reporting system means a statewide system for facilitating the real-time electronic reporting of surface transportation incidents to a central location for use in monitoring the event, providing accurate traveler information, and responding to the incident as appropriate. This definition is consistent with Public Law 109-59; 119 Stat. 1144, Section 1201(f).

Timeliness means the degree to which data values or a set of values are provided at the time required or specified.

Traffic and travel conditions means the characteristics that the traveling public experiences. Traffic and travel conditions include, but are not limited to, the following characteristics:

(1) Road or lane closures because of construction, traffic incidents, or other events;

(2) Roadway weather or other environmental conditions restricting or adversely affecting travel; and

(3) Travel times or speeds on limited access roadways in metropolitan areas that experience recurring congestion.

Validity means the degree to which data values fall within the respective domain of acceptable values.

Value-added information products means crafted products intended for commercial use, for sale to a customer base, or for other commercial enterprise purposes. These products may be derived from information gathered by States and may be created from other party or proprietary sources. These products may be created using the unique means of the value-added information provider.

§511.305 Policy.

This part establishes the provisions and parameters for the Real-Time System Management Information Program for State DOTs, other responsible agencies, and partnerships with other commercial entities in establishing real-time information programs that provide accessibility to traffic and travel conditions information by other public agencies, the traveling public, and by other parties who may deliver value-added information products.

§511.307 Eligibility for Federal funding.

(a) Subject to project approval by the Secretary, a State may obligate funds apportioned to the State under Title 23 U.S.C. sections 104(b)(1), also known as National Highway System funds, 104(b)(2), also known as CMAQ Improvement funds, and 104(b)(3), also known as STP funds, for activities relating to the planning, deployment and operation, including preventative maintenance, of real-time monitoring elements that advance the goals and purposes of the Real-Time System Management Information Program. The SPC funds, apportioned according to 23 U.S.C. 505(a), may be applied to the development and implementation of a real-time information program.

(b) Those project applications to establish a real-time information program solely for Interstate System highways are entitled to a Federal share of 90 percent of the total project cost, pursuant to 23 U.S.C. 120(a). Those project applications to establish a real-time information program for non-Interstate highways are entitled to a Federal share of 80 percent of the total project cost, as per 23 U.S.C. 120(b).

§511.309 Provisions for traffic and travel conditions reporting.

(a) Minimum requirements for traffic and travel conditions made available by real-time information programs are:

(1) Construction activities. The timeliness for the availability of information about full construction activities that close or reopen roadways or lanes will be 20 minutes or less from the time of the closure for highways outside of Metropolitan Areas. For roadways within Metropolitan Areas, the timeliness for the availability of information about full construction activities that close or reopen roadways or lanes will be 10 minutes or less from the time of the closure or reopening. Short-term or intermittent lane closures of limited duration that are less than the required reporting times are not included as a minimum requirement under this section.

(2) Roadway or lane blocking incidents. The timeliness for the availability of information related to roadway or lane blocking traffic incidents will be 20 minutes or less from the time that the incident is verified for highways outside of Metropolitan Areas. For roadways within Metropolitan Areas, the timeliness for the availability of information related to roadway or lane blocking traffic incidents will be 10 minutes or less from the time that the incident is verified.

(3) Roadway weather observations. The timeliness for the availability of information about hazardous driving conditions and roadway or lane closures or blockages because of adverse weather conditions will be 20 minutes or less from the time the hazardous conditions, blockage, or closure is observed.

(4) Travel time information. The timeliness for the availability of travel time information along limited access roadway segments within Metropolitan Areas, as defined under this subpart, will be 10 minutes or less from the time that the travel time calculation is completed.

(5) Information accuracy. The designed accuracy for a real-time information program shall be 85 percent accurate at a minimum, or have a maximum error rate of 15 percent.

(6) Information availability. The designed availability for a real-time information program shall be 90 percent available at a minimum.

(b) Real-time information programs may be established using legacy monitoring mechanisms applied to the highways, using a statewide incident reporting system, using new monitoring mechanisms applied to the highways, using value-added information products, or using a combination of monitoring mechanisms and value-added information products.

§511.311 Real-time information program establishment.

(a) Requirement. States shall establish real-time information programs that are consistent with the parameters defined under §511.309. The real-time information program shall be established to take advantage of the existing traffic and travel condition monitoring capabilities, and build upon them where applicable. The real-time information program shall include traffic and travel condition information for, as a minimum, all the Interstate highways operated by the State. In addition, the real-time information program shall complement current transportation performance reporting systems by making it easier to gather or enhance required information.

(b) Data quality. States shall develop the methods by which data quality can be ensured to the data consumers. The criteria for defining the validity of traffic and travel conditions made available from real-time information programs shall be established by the States in collaboration with their partners for establishing the programs. States shall receive FHWA's concurrence that the selected methods provide reasonable checks of the quality of the information made available by the real-time information program. In requesting FHWA's concurrence, the State shall demonstrate to FHWA how the selected methods gauge the accuracy and availability of the real-time information and the remedial actions if the information quality falls below the levels described in § 511.309(a)(5) and 5511.309(a)(6).

(c) Participation. The establishment, or the enhancement, of a real-time information program should include participation from the following agencies: Highway agencies; public safety agencies (e.g., police, fire, emergency/medical); transit operators; and other operating agencies necessary to sustain mobility through the region and/or the metropolitan area. Nothing in this subpart is intended to alter the existing relationships among State, regional, and local agencies.

(d) Update of Regional ITS Architecture. All States and regions that have created a Regional ITS Architecture in accordance with Section 940 in Title 23 CFR shall evaluate their Regional ITS Architectures to determine whether the Regional ITS Architectures explicitly address real-time highway and transit information needs and the methods needed to meet such needs. Traffic and travel conditions monitoring needs for all Interstate system highways shall be considered. If necessary, the Regional ITS Architectures shall be updated to address coverage, monitoring systems, data fusion and archiving, and accessibility to highway and transit information for other

States and for value added Information product providers. The Regional ITS Architecture shall feature the components and functionality of the real-time information program.

(e) Effective date. Establishment of the real-time information program for traffic and travel conditions on the Interstate system highways shall be completed no later than November 8, 2014.

§511.313 Metropolitan Area real-time information program supplement.

(a) Applicability. Metropolitan Areas as defined under this subpart.

(b) Requirement. Metropolitan Areas shall establish a real-time information program for traffic and travel conditions reporting with the same provisions described in §511.311.

(c) Routes of significance. States shall designate metropolitan areas, non-Interstate highways that are routes of significance as defined under this subpart. In identifying the metropolitan routes of significance, States shall collaborate with local or regional agencies using existing coordination methods. Nothing in this subpart is intended to alter the existing relationships among State, regional, and local agencies.

(d) Effective date. Establishment of the real-time information program for traffic and travel conditions reporting along the Metropolitan Area Interstate system highways shall be completed no later than November 8, 2014. Establishment of the real-time information program for traffic and travel conditions reporting along the State-designated metropolitan area routes of significance shall be completed no later than November 8, 2016.

§511.315 Program administration.

Compliance with this subpart will be monitored under Federal-aid oversight procedures as provided under 23 U.S.C. 106 and 133, 23 CFR 1.36, and 23 CFR 940.13.

4. Glossary

To include additional descriptions/abbreviations used primarily in the module.

Term	Definition
Concept of Operations	A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.
Data Exchange Format Specification (DXFS)	A standards-based specification of key RTSMIP interfaces.
Real-Time System Management Information Program (RTSMIP)	The real-time system management information program (RTSMIP) was defined in Section 1201 of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU), published in August 2005, to provide in all states, the capability to monitor, in real-time, the traffic and travel conditions of the major highways of the United States and to share that information to improve the security of the surface transportation system, to address congestion problems, to support improved response to weather events and surface transportation incidents, and facilitate national and regional highway traveler information.
Standards Development Organization (SDO)	Organizations that develop, publish, and revise technical standards.
Systems Engineering Process (SEP)	An inter-disciplinary approach and means to enable the realization of successful systems.

5. References

ITS Standards Program: https://www.standards.its.dot.gov

SEP FHWA Guidance: https://ops.fhwa.dot.gov/int its deployment/sys eng.htm

Regional ITS Architecture: https://ops.fhwa.dot.gov/its arch imp/index.htm

ITS ePrimer Module 7: Public Transportation: eprimer/module7.aspx#opsmgmt

ITS ePrimer Module 2: Systems Engineering eprimer/module2.aspx#opsmgmt

FTA Transit Intelligent Transportation System Architecture Consistency Review - 2010 Update https://www.transit.dot.gov/sites/fta.dot.gov/files/docs/2010TransitITSArchRvw_-_08.29.2011.pdf.

6. Study Questions

1. What are some benefits of using ITS Standards?

1. Facilitates regional interoperability
2. Supports compliance to FTA Policy on ITS Architecture and Standards
3. Facilitates systems integration
4. All of the above

2. What is the relationship between the steps on the left of the Vee and the right?

1. No relationship between left and right
2. System definition left used to verify system on right
3. Items on left performed after items on right

3. ITS Standards are typically first used in what step in the SE Process?

1. Concept of Operations
2. Requirements
3. Design - High Level and Detailed
4. HW and SW development

4. Agencies have found which of the following to be a technical challenge of using ITS Standards?

1. Inconsistent industry support
2. Needed standards are not mature
3. Using standards is a paradigm shift for agency
4. All of the above