Tennessee Procedures for Implementing ITS Regulations (23CFR940)
1. A Systems Engineering Analysis (SEA) shall be demonstrated for any ITS project using Federal Funds, and should be done for projects without Federal Funds. Those projects, which FHWA approves, that can demonstrate a SEA under Tennessee Department of Transportation (TDOT) development process as documented in the TDOT Traffic Design Guidelines are categorically excluded. “Categorically Excluded “projects are those that do not feature a central control, or the sharing of data.
Listed below are examples of such projects:
1) Projects that should be in a Regional/Statewide Architecture
a) Multi-modal or multi-jurisdictional projects that connect systems from different agencies, examples are:
i) Signal synchronization project (connecting signals from two jurisdictions.
ii) Traffic signal pre-emption (connecting city field equipment with emergency vehicles.
b) New system developments that must consider future integration requirements, examples are:
i) new installation of speeding or red-light-running electronic ticketing systems (new functionality integrated with Traffic Management Center (TMC), could lead to future integration between highway and law enforcement)
ii) new installation of variable speed-limit signs (new functionality integrated with TMC, could lead to future integration between highway and law enforcement)
iii) new curve warning sensor system on ramps (new functionality integrated with TMC)
iv) downhill speed detection and warning system (new functionality integrated with TMC)
v) downhill speed detection and warning systems (new functionality integrated with TMC)
vi) new Automated Vehicle Location equipment on buses (new functionality integrated with TMC)
2) Projects that do not have to be in a Regional/Statewide Architecture
a) Projects that have no reasonable opportunity for future integration, examples are:
i) installation of isolated rural traffic signals
ii) isolated speeding or red-light running electronic ticketing system (new functionality, but no plans to integrate with TMC)
iii) isolated curve warning sensor system
b) System expansions that add no new interfaces and no new functionality
i) adding additional CCTV cameras to an existing system
ii) adding additional DMS to an existing system
c) Projects that enhance current system operation, but add no new interfaces or functionality
i) upgrade of a closed loop traffic signal system with no plans to other traffic signal systems
2. The following steps detail the process for satisfying the ITS Regulations. Contact Federal Highway Administration (FHWA) Tennessee Division Safety and Traffic Operations team for any questions on these ITS requirements or procedures.
2.1. Determine if a project is ITS.
An ITS project is a project which acquires technology and contributes to
providing an ITS User Service. See FIGURE 1 for a list of ITS User Services.
2.2. A SEA is a process or a structured way of thinking that can control costs, lead to
Reduced risks, maintain the project schedule, satisfy users’ needs, and meet the
Requirements of the Federal Regulation. The SEA will vary based on the
Complexity of the ITS project, but shall address at a minimum:
§ identification of portions of the regional architecture being implemented;
§ identification of participating agencies roles and responsibilities;
§ requirement definitions
§ analysis of alternative system configurations and technology options to meet requirements;
§ procurement options;
§ identification of applicable ITS standards and testing procedures; and
§ Procedures and resources necessary for operations and management of the system.
NOTE: An example of a basic SEA to address the seven bullets is presented in Figure 3.
This form may not be suited for major ITS projects.
2.2.1. To identify which portions of the applicable ITS architecture are being
Implemented, use the following guidelines:
2.2.1.1. An ITS project falls within the boundaries of an ITS architecture
(See FIGURE 2):
2.2.1.1.1. If the project functions exist, provide verification that the
Project functions and or information flow exist.
2.2.1.1.2. If some project functions and/or information flows do not exist
In the ITS architecture: Copy the appropriate pages from the
ITS architecture and indicate the existing data flows that will
Be implemented on the project and add the data flows that are
Going to be implemented. All parts of the ITS architecture
Must be reviewed to determine which new project functions
And/or data flows are affected by the new project functions.
All changes must be coordinated and documented with the
Systems planning and Policy Office and the maintaining
Agency of the ITS architecture must be notified of the changes.
2.2.1.1.3. If no project functions exist in the ITS architecture: a project
Level architecture, addressing all elements of the ITS
Architecture, will be created utilizing the state/regional ITS
Architecture and the national ITS architecture as a basis. All
Changes must be documented and the maintaining agency for
For the ITS architecture must be notified of the changes.
2.2.1.1.4. For subsequent projects in the region, until the 4 years have
Passed or the ITS architecture is developed, which ever is
Earlier, a project level architecture, as described in 23CFR940,
Shall use the National ITS architecture as a basis.
2.2.2. If an ITS project falls outside the boundaries of an existing ITS
Architecture area (See FIGURE 2), determine if the ITS project
Should be added to an existing ITS architecture. This decision will
Be based upon geographic, stakeholder and system function
Considerations:
2.2.2.1. If it can be added to an existing ITS architecture, refer to
Section 2.2.1.1.3 above.
2.2.2.2. If the new ITS project will not be added to an existing ITS
Architecture, then a project level architecture, as described in
23CFR940, will need to be created using the national ITS
architecture as a basis. If this is the first ITS project in the
region, the timeframe for developing an ITS architecture starts.
The region will have 4 years from the date the project is
authorized by the FHWA Tennessee Division Office to create
an ITS architecture that is “Ready for Use”.
2.3 Once the 4 years have passed, ITS projects cannot be authorized for
construction with federal funds until the ITS Architecture has been
determined to be “Ready for Use” by the stakeholders.
2.4. The Systems Planning and Policy Office will maintain the statewide ITS
Architecture. The Long Range Planning Division will assist the MPO’s
in developing Regional Architectures and oversee the maintenance of all
Regional Architectures.
2.4.1. The Systems Planning and Policy Office will review and approve all
Regional Architectures before submitting to FHWA for concurrence
of “Ready for Use” approval.
2.4.2. The Long Range Planning Division will oversee the bi-monthly meeting
of the ITS Coordinating Committee, including distribution of the Agenda
and minutes to each stakeholder on the committee.
2.4.2.1. The Systems Planning and Policy Office shall develop a draft
priority list for near term projects in coordination with the
directors and Regional Planning Office (RPO) coordinators.
2.4.2.2. The draft priority list will be reviewed and discussed by the ITS
Coordinating Committee before final recommendations are made.
2.4.3. The Long Range Planning Division will update the ITS Annual Strategic
Plan for proposed work activities for the upcoming year.
3. Use of Turbo Architecture is highly recommended, but not required to create any ITS
architecture. Turbo Architecture offers a flexible system that uses an interview process
to assist in creating an ITS architecture, allows easy adjustments, automated diagram
updates, and allows for quick and easy integration of one architecture into another with
limited data re-entry. Training on Turbo Architecture is offered through the National
Highway Institute and may be coordinated through the FHWA TN Division Safety and
Traffic Operations Team.
4. Current FHWA-TDOT Oversight and Stewardship Agreement indicates that FHWA
will approve the SEA for full oversight projects (FOP) for consistency with the federal
regulations. TDOT and MPO will retain approval for project selection and
programming. Once documents have been evaluated, FHWA will notify TDOT, the
local agency and the appropriate MPO of the results.
5. When an oversight project design is completed, a SEA shall be submitted to FHWA.
When the project construction is completed, the FHWA Division Office needs to be
notified in order to complete the project tracking cycle.
TDOT/FHWA ENGINEERING ANALYSIS FOR ITS
A Systems Engineering Analysis (SEA) is a process or structured way of thinking which can control costs, lead to reduced risks, maintain the project schedule, satisfy user needs and meet Federal requirements. This form is a simplified SEA which will apply to most basic ITS projects. For projects involving a high level of complexity, a customized SEA may be required.
Project Number |
|
Project Description |
|
Project Location (Route, City/County) |
|
Project Contact and Number |
|
1) Identify, by reference, portions of the Regional or Statewide Architecture that relate to the functions being implemented in this project. ____________________
2) Identify participating agencies, roles and responsibilities: List each agency (including yours) that will be involved in the project and indicate what their responsibility will be by checking the boxes. If funding is through TDOT, list TDOT as a partner.
Partner Name |
Purchase Equipment |
Oversee Project Installation |
Operate Equipment |
Fund Equipment Operations |
Maintain Equipment |
Fund Maintenance |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
F – Formal Agreement I – Informal Agreement N – In Negotiation NA – None required
3) Requirements definitions; What do you want the system to do from a functional standpoint? Specifically, what, not how, the system will function (i.e.; GOOD: the system shall allow a user to log into a computer, BAD: The system shall use state of the art technology) The system shall:
a) |
|
b) |
|
c) |
|
4) Analysis of alternative system configurations and technology options;
Alternative |
Comments |
|
|
|
|
|
|
5) Procurement; Low Bid ( ) Other ___________________________________________________________
6) Identification of applicable ITS Project standards to identify standards implemented in this project (see attached)
7) Procedures and resources necessary for operation and management of the system;
8) Design: Local Design ( ) TDOT Design ( ) Consultant Design ( )
Attach additional sheets if more space needed for responses.
Relevant ITS Project Standards for ITS Projects
(Item 6 on SEA Form)
Directions: Check each standard your agency will use for this project. If you need more information on any standard listed below, go to http://www.standards.its.dot.gov/ and click on development status or fact sheets for the latest information. All bolded standards are highly recommended for use as they have been published and approved by the Standards Development Organization.
Signal Interconnect Standards:
1 AASHTO/ITE/NEMA Global Object Definitions NTCIP 1201
1 AASHTO/ITE/NEMA Object Definitions for Actuated Traffic Signal Controller Units NTCIP 1202
1 AASHTO/ITE/NEMA Data Dictionary for Closed Circuit Television (CCTV) NTCIP 1205
1 AASHTO/ITE/NEMA Object Definitions for Video Switches NTCIP 1208
1 AASHTO/ITE/NEMA Transportation System Sensor Objects NTCIP 1209
1 AASHTO/ITE/NEMA Objects for Signal Systems Masters NTCIP 1210
1 AASHTO/ITE/NEMA Objects for Signal System Control Priority NTCIP 1211
1 Simple Transportation Management Framework (STMF) NTCIP 1101
1 Base Standard: Octet Encoding Rules (OER) NTCIP 1102
1 Simple Transportation Management Protocol NTCIP 1103
1 Class B Profile NTCIP 2001
1 Point to Multi-Point Protocol Using RS-232 Subnetwork Profile NTCIP 2101
1 Subnet Profile for PMPP Over FSK modems NTCIP 2102
1 Subnet Profile for Point to Point Protocol using RS 232 NTCIP 2103
1 Subnet Profile for Ethernet NTCIP 2104
1 Transportation Transport Profile NTCIP 2201
1 Internet (TCP/IP and UDP/IP) Transport Profile NTCIP 2202
1 Application Profile for Simple Transportation Management Framework (STMF) NTCIP 2301
1 Application Profile for Trivial File transportation Protocol NTCIP 2302
1 Application Profile for File Transfer Protocol (FTP) NTCIP 2303
If no Signal Interconnect Standards are to be used, attach explanation.
Signal Pre-emption Standards:
1 AASHTO/ITE/NEMA Global Object Definitions NTCIP 1201
1 AASHTO/ITE/NEMA Object Definitions for Actuated Traffic Signal Controller Units NTCIP 1202
1 AASHTO/ITE/NEMA Objects for Signal Systems Masters NTCIP 1210
1 AASHTO/ITE/NEMA Objects for Signal System Control Priority NTCIP 1211
1 Simple Transportation Management Framework (STMF) NTCIP 1101
1 Base Standard: Octet Encoding Rules (OER) NTCIP 1102
1 Simple Transportation Management Protocol NTCIP 1103
1 Class B Profile NTCIP 2001
1 Point to Multi-Point Protocol Using RS-232 Subnetwork Profile NTCIP 2101
1 Subnet Profile for PMPP Over FSK modems NTCIP 2102
1 Subnet Profile for Point to Point Protocol using RS 232 NTCIP 2103
1 Subnet Profile for Ethernet NTCIP 2104
1 Transportation Transport Profile NTCIP 2201
1 Internet (TCP/IP and UDP/IP) Transport Profile NTCIP 2202
1 Application Profile for Simple Transportation Management Framework (STMF) NTCIP 2301
1 Application Profile for Trivial File transportation Protocol NTCIP 2302
1 Application Profile for File Transfer Protocol (FTP) NTCIP 2303
1 ASTM Standard Specification for 5.9 gHz Data Link Layer ASTM 5 gHz Data Link
1 ASTM Standard Specification for 5.9 gHz Physical Layer ASTM 5 gHz Phys
1 ASTM Specification for Dedicated Short Range Communication ASTM PS
(DSRC) Data Link Layer: Medium Access Logical Link Control 105-99
1 ASTM Specification for Dedicated Short Range Communication ASTM
(DSRC) Physical Layer using Microwave in the 902-928 mHz E2 158-01
1 IEEE Security/Privacy of Vehicle/RS Communications including Smart Card IEEE P1556
If no Signal Interconnect Standards are to be used, attach explanation.
Standards Completed By: (Print Name) |
|
Title/Agency |
|
Signature/Date |
|