1300 ITS Traffic Engineering Manual

Transcription

1 TABLE OF CONTENTS Part 13 - INTELLIGENT TRANSPORTATION SYSTEMS (ITS) 1300 GENERAL CFR 940 COMPLIANCE General Background Introduction and Scope General Criteria Architecture General Architecture Conformity Project Level ITS Architecture If a Regional Architecture Exists If a Regional Architecture Does Not Exist Systems Engineering Analysis (SEA) General Systems Engineering Analysis Documentation Additional Requirements Ellis Requirements for ITS Projects FREEWAY MANAGEMENT SYSTEM ON ODOT-MAINTAINED HWYS General Traffic Management Center (TMC) Closed Circuit Television (CCTV) Communication Dynamic Message Signs (DMS) Vehicle Detection Highway Advisory Radio (HAR) Travel Time Road Weather Information System (RWIS) Ramp Metering Traffic Incident Management SPECIFICATIONS FORMS INDEX TABLES INDEX Exempt, Low-Risk and High-Risk ITS Projects ITS User Services Regional ITS Architectures in Ohio FIGURES INDEX Project Development Process (PDP) Fiber Optics Termination Diagram (Node Cabinet Assembly) Fiber Optics Termination Diagram (Underground Splice Enclosure) Fiber Optics Termination Diagram (Fiber Backbone Splice Chart) ITS Device Communication Diagram (January 16, 2015) October 23,

2 Intentionally blank October 23, 2002 (January 16, 2015)

3 Part 13 - INTELLIGENT TRANSPORTATION SYSTEMS 1300 GENERAL This Part of the TEM addresses policies, guidelines, standard procedures, etc. related to Intelligent Transportation Systems (ITS), which in this context means electronics, communications, or information processing used singly or in combination to improve the efficiency or safety of a surface transportation system. Deployment and operation of these systems requires specialized coordination, design and device specifications, procurement/construction, and management. The Office of Traffic Operations (OTO) shall provide implementation plans for ITS and policies for ITS operation CFR 940 Compliance General Background Federal Regulation 23 CFR 940 requires ITS projects and traditional projects with ITS components funded through the highway trust fund to conform to the National ITS Architecture and applicable standards. The Ohio Procedures for Implementing ITS Regulations (23 CFR 940) documents the requirements to be used in Ohio for any ITS project utilizing Federal funds. These requirements apply to the ITS components. The Ohio procedures incorporate guidance from several sources, including 23 CFR 940, the Programmatic Agreement for ITS Systems Engineering Analysis between the Federal Highway Administration s (FHWA) Ohio Division Offices and ODOT and the Federal-Aid Highway Program Stewardship and Oversight Agreement. ODOT s interpretation of the Federal policy provides a streamlined process to address project definitions, ITS architecture modifications, and systems engineering. This approach will permit ODOT and FHWA to establish concurrence in the level of ITS assessment and documentation needed. As this is a Federal requirement for funding, it is imperative for ODOT to effectively administer this process so as to not adversely affect project delivery. ODOT will collaborate with the Ohio Division of FHWA to guide ODOT District offices and local agencies through the documentation for ITS projects. The requirements in 23 CFR 940 include provisions for interoperability and future integration of equipment, software and systems. This FHWA requirement is similar to other separate and distinct Federal requirements which are accepted and are an inherent part of the project development process. This section provides guidance for using ODOT s Project Development Process (PDP), L&D Manual and TEM for mainstreaming these requirements. A major component of the CFR 940 documentation is the testing plan. The Programmatic Agreement for ITS Systems Engineering Analysis utilizes a risk-based approach to establish a streamlined process for the required Systems Engineering Analysis documentation. See Section for information on the risk-based Systems Engineering Analysis. Revised April 18, 2014 October 23,

4 Introduction and Scope These requirements apply to Federal Aid projects, as required by 23 CFR 940, the Programmatic Agreement for ITS Systems Engineering Analysis between FHWA s Ohio Division and ODOT and the Ohio Federal-aid Highway Program Stewardship and Oversight Agreement. It is recommended that State-funded projects follow the same process for regional consistency. In accordance with 23 CFR 940, ITS projects funded through the highway trust fund shall conform to the National ITS Architecture and applicable standards. 23 CFR 940 also stipulates that conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a Regional ITS Architecture, as applicable, and the subsequent adherence of all ITS projects to that Regional ITS Architecture. This section outlines the ODOT procedures for implementing these requirements. The level of documentation should be commensurate with the project scope. The flowchart in Figure further illustrates the procedures described below. ODOT-administered ITS projects shall follow the Programmatic Agreement for ITS Systems Engineering Analysis between FHWA s Ohio Division and ODOT and the current Ohio Federal-aid Highway Program Stewardship and Oversight Agreement with regard to oversight of the projects. Local agency project coordination for ITS projects will be through the ODOT District with coordination through the ODOT Office of Traffic Operations and FHWA Ohio Division Office, as applicable, for concurrence in the level of ITS assessment and documentation required General Criteria In accordance with 23 CFR 940.3, an ITS project is 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 and summarized in Table In Ohio, a project would be considered to be an ITS project if it meets any of the following: 1. It requires the integration of multiple separate systems. 2. It is a project that has significant potential to involve the integration of technologies on a multi-jurisdictional level. 3. It replaces existing or installs new centrally controlled software. For non-freeway Management System projects, a project, even one meeting the above criteria illustrated by the examples below and in Table , would not be considered an ITS project if it is an expansion of an existing system and does not add functionality. However, expansion of a Freeway Management System through additional phases is always considered an ITS project. Enforcement systems and systems used primarily to gather and archive data not directly used for operational purposes are not generally considered to be ITS. ITS projects come with various risk factors, such as cost overruns, not meeting agency needs and system failure. The level of risk varies depending on the presence of the following factors: 1. Number of jurisdictions and/or modes involved. 2. Extent of new, unproven software creation. 3. Extent of new, unproven hardware and communication technology being used. 4. Number and level of complexity of new interfaces to other systems. 5. Level of detail needed in defining the functional requirements. 6. Level of detail needed in defining the operations and management procedures October 23, 2002 Revised April 18, 2014

5 7. Service life of the equipment and software technology. The risk-based Systems Engineering Analysis approach classifies ITS projects into three types: Exempt, Low-Risk and High-Risk. For examples of Exempt, Low-Risk and High-Risk projects see Table The decisive factor in this determination is the scale and complexity of the project Architecture General In areas served by a Metropolitan Planning Organization (MPO), the MPO needs to identify potential transit and highway ITS projects to the ODOT District when reviewing local programs for inclusion in the Transportation Infrastructure Plan TIP. In areas not served by an MPO, the ODOT Local Project Administrator (LPA) needs to perform this identifying function. It shall be the responsibility of the ODOT District to determine if a project is an ITS project, and if so, to identify it as an Exempt, Low-Risk or High-Risk. ITS Project. If the determination of whether a project is ITS or non-its, or whether a project is an Exempt, Low- Risk or High-Risk.ITS Project is not obvious, the project shall be discussed with the Office of Traffic Operations to make a determination. The District will notify the MPO and the project sponsor of the determination in writing. An ITS Project will require a more comprehensive effort that analyzes several options for each type of technology selected, since these types of projects tend to be multifaceted. Generally, there are several elements that need to be evaluated and more options are analyzed in an ITS Project. If a consultant is used for an ITS Project, these procedures should be included in the consultant s Scope of Work Architecture Conformity To ensure conformity with 23 CFR 940, several requirements must be met. The rule stipulates that conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a Regional ITS Architecture, and the subsequent adherence of all ITS projects to that Regional ITS Architecture. According to 23 CFR 940.3, a Regional ITS Architecture is a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects. It documents data flows and subsystems, roles and responsibilities, operating agreements, and ITS Standards to be used for a particular region. In Ohio, Regional ITS Architectures generally encompass an MPO area. A Statewide ITS Architecture is a form of a Regional ITS Architecture. Ohio is currently developing a statewide ITS architecture. See Table for a listing of Regional ITS Architectures in Ohio Project Level ITS Architecture A Project Level ITS Architecture, according to 23 CFR is a framework that identifies the institutional agreement and technical integration necessary to interface an ITS project with other ITS projects and systems. The Project Level ITS Architecture indicates the data flows and subsystems that the project will implement. To achieve the significant benefits derived from the documentation, a Project Level ITS Architecture needs to be developed for all ITS Projects. For further information, refer to Subsection , Systems Engineering Analysis Documentation If a Regional ITS Architecture Exists If an ITS project falls within the boundaries of a Regional ITS Architecture (see Table ) the Project Level ITS Architecture should be developed as follows: Revised April 18, 2014 October 23,

6 1. If the project functions exist in the Regional ITS Architecture: Copy the appropriate pages from the Regional ITS Architecture and use a highlighter to highlight the data flows that will be implemented by the project. This highlighting will satisfy the requirements for a Project Level ITS Architecture. 2. If some project functions do not exist in the Regional Architecture: The Project Level ITS Architecture must supplement the Regional ITS Architecture with any missing data flows. Copy the appropriate pages from the Regional ITS Architecture and use a highlighter to highlight the existing data flows that will be implemented by the project and add the additional data flows that will be implemented. The MPO maintaining the Regional ITS Architecture also needs to be notified of the changes, for purposes of updating the Regional ITS Architecture. 3. If none of the project functions exist in the Regional ITS Architecture: A Project Level ITS Architecture shall be created, using as a base the Regional ITS Architecture and the National ITS Architecture. The MPO maintaining the Regional ITS Architecture shall be notified of the changes, for purposes of updating the Regional ITS Architecture. The final design of all ITS projects 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 discrepancies shall be reconciled and the Regional ITS Architecture or the project shall be modified as appropriate If a Regional ITS Architecture Does Not Exist In the future, when a statewide ITS architecture is available (see Section ) if an ITS project falls in an area not covered by the boundaries of a Regional ITS architecture (see Table ), the statewide provisions will apply. Currently, if an ITS project falls in an area not covered by the boundaries of a Regional ITS Architecture, a few additional procedures will be required in the development of the Project Level ITS Architecture. First, determine if the ITS project should be added to an existing Regional ITS Architecture. The decision should be based upon geographic, stakeholder, and system function considerations. If the new ITS project will not be added to an existing Regional ITS Architecture, then Project Level ITS Architecture will need to be created using the National ITS Architecture as a basis. If this is the first ITS project in the area, the timeframe for developing a Regional ITS Architecture begins, and the Region will have four years from the date that the project advances to final design to create a Regional ITS Architecture that is Ready for Use. Final design is defined as entry to Stage 3 Design at the appropriate step of the PDP. For subsequent projects in the Region, until the four years have passed or the Regional ITS Architecture is developed, whichever is earlier, Project Level ITS Architecture shall use the National ITS Architecture as a basis. For Federal funds to be considered once the four years have passed, the Regional ITS Architecture must be completed for ITS projects to be authorized for construction Systems Engineering Analysis (SEA) General In Ohio, all ITS projects shall be based on a Systems Engineering Analysis (SEA). This is a process or a structured approach which can control costs, lead to reduced risks, maintain the project schedule, satisfy user needs, and meet the requirements of ODOT and the Federal 13-6 October 23, 2002 Revised April 18, 2014

7 regulation. The SEA effort will vary based on the level of risk associated with the ITS project. ITS Projects are classified into three types: Exempt, Low-Risk and High-Risk. Exempt ITS Projects do not require Systems Engineering Analysis documentation, nor any ITS-specific approval action, as long as they only affect one maintaining agency. Exempt ITS projects affecting multiple agencies are also considered exempt if there is an Operations and Management Agreement between the affected agencies that details the procedures and resources necessary for the operations and management of the system. Projects affecting multiple agencies without such an agreement are considered High-Risk and require a projectspecific Systems Engineering Analysis be completed and approved. See Table for projects that classify as Exempt ITS Projects. Low-Risk ITS projects shall utilize a Systems Engineering Review Form (SERF) to assess the level of risk and confirm that it is indeed low risk. If all of the questions on the SERF are answered in the affirmative, i.e. Yes, then the project can be considered Low-Risk. The SERF will also document that the project is in conformance with the Functional Requirements document for that particular project category and the Systems Engineering Analysis requirements of 23 CFR See Table for projects that classify as Low-Risk ITS Projects. See Section for information on completing a Systems Engineering Review Form (SERF) for these projects. High-Risk ITS projects require a project-specific Systems Engineering Analysis be completed and approved. These types of projects typically involve new or unproven technology, multiple maintaining agencies and/or new hardware, software or interfaces. See Table for projects that classify as High-Risk ITS Projects. For High-Risk ITS projects, an SEA will provide: a description of the scope of the ITS project (the general location, conceptual alternative, and logical termini or service area of the proposed project); a concept of operations that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the ITS project; functional requirements of the ITS project; interface requirements and information exchanges between the ITS project and other planned and existing systems and subsystems; and identification of applicable ITS standards. The scale of the analysis should be commensurate with the project scope of the ITS portion of the project. In Ohio, the full SEA is comprised of twelve Items to be addressed, which further describe these elements. The twelve items are elaborated in Subsection , Systems Engineering Analysis Documentation. ITS projects are required to follow the Project Development Process (PDP), see TEM Figure The various SEA documents (see Subsections and ) are to be developed and submitted at the appropriate point in the project. For Design-Build projects, reference the Office of Traffic Operations in the Plan Notes with the following contact information: Office of Traffic Operations Phone: Fax: cen.its.lab@dot.state.oh.us Revised April 18, 2014 October 23,

8 Systems Engineering Analysis Documentation All submissions required by the PDP (see Sections and L&D Manual Volume 1) shall be required for ITS projects. A Project Level ITS Architecture and a Systems Engineering Analysis (SEA) are required for any High-Risk ITS project. The documentation is expected to be commensurate with the scope of the ITS work. Both the Project Level ITS Architecture and the SEA must be completed and approved prior to authorization of construction funding. For examples of how to address SEA Items 1-12 for some projects, refer to Form For clarity, page breaks should be inserted between each of the twelve items. The SEA will consist of providing items 1 through 12, listed below: SEA Item #1 - Define the scope of work for the project (the general location, conceptual alternative, and logical termini or service area of the proposed project). Scoping shall also include inter-agency coordination and possible effects on neighboring jurisdictions. Define the scope of work for the overall project and the ITS components (the general location, conceptual alternative, level of development and logical termini or service area of the proposed project) Scoping shall also include inter-agency coordination and possible effects on neighboring jurisdictions. Include the PID, location, project description from ELLIS or other sources, description of the ITS work, and the project background (summary of purpose and need). Be as descriptive as possible and briefly address any proprietary equipment/software requirements. SEA Item #2 - Identify portions of the Regional ITS Architecture being implemented. Identify 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. Include identification of the ITS User Services which will apply to the project and a graphic from the Regional ITS Architecture illustrating the data flows that will be incorporated. Inclusion of SEA Item #2 will satisfy the Project Level ITS Architecture requirements. The use of the FHWA software product TurboArchitecture is highly recommended. This software can be downloaded free of charge from the FHWA. If no Regional ITS Architecture exists for the project area, contact the ODOT Office of Traffic Operations (OTO). SEA Item #3 - Provide a list of all stakeholders, including the roles and responsibilities of each and the Operational Concept and Concept of Operations. Provide a list of stakeholders that have a direct role in the project. Provide an Operational Concept. The Operational Concept is a high level description of the roles and responsibilities of the primary stakeholders and the systems they operate. Provide a Concept of Operations. The Concept of Operations is a more detailed description of how the system will be used. It should discuss what the project is to accomplish, including identifying stakeholder needs and resources that stakeholders can provide. It is nontechnical and provides a bridge between the needs motivating the project and the specific technical requirements. The greater the expected impact on operations, the more detailed explanation will be required. For complex projects, operational scenarios may be necessary to illustrate the operations. SEA Item #4 - Define the functional requirements of the project October 23, 2002 Revised April 18, 2014

9 The functional requirements of the project describe how the project will be built and operated and typically are based upon the ITS Market Packages. High level functional requirements should be listed and can further be used to develop specific contract specifications language. Provide interface/communication requirements for all stakeholders in the project. This includes the existing systems already deployed in the region. Functional requirements are statements of the capabilities that a system must have ( functions ), geared to addressing the business needs that a system must satisfy. Business needs are the objectives for which the system is built. These functional requirements will be traced through the life of the project. A key aspect of the functional requirements is that they address what a system must do, but does not address how the system should accomplish the what. In other words, a functional requirement should not go into the details of how to implement the function. For more information on functional requirements, see the USDOT publication Developing Functional Requirements for ITS Projects which is available on the FHWA website SEA Item #5 - Provide analysis of alternative system configurations and technology options to meet requirements, including rationale for technology selection. Describe the basis of the project scope and how it was developed. Identify any proprietary items and explain the necessity and rationale for these items. Show the link between the system design concept and the operations and maintenance of the constructed project. SEA Item #6 - Provide analysis of procurement methods considered including rationale for selected option. Describe possible procurement methods for the design, construction, and operations/ maintenance (as applicable) of the project and why the preferred method was selected. In some cases, the procurement methods may be determined by State law. SEA Item #7 - Identify the existing ITS Standards that will be used in the project. An explanation is required for not using the applicable Standards. ITS Standards are available on-line from the FHWA website. List all ITS Standards which may be applicable to the project, indicate if the Standard is to be used in the project, and if not used, provide an explanation of why they are not being used. SEA Item #8 - Identify the testing procedures to verify compliance with the standards as well as the requirement for interoperability. The testing procedures verify the individual elements of the project comply with the project specifications. The specifications are based upon the high level functional requirements identified in SEA Item #4. For some projects, the testing procedures may be provided by a product vendor. Project submittal cut sheets, laboratory reports and precertification may be substituted for some field testing. Devices on a Qualified Providers List (QPL) do not need to be tested. Other devices or additional functionality will be included on the traceability matrix for field testing. SEA Item #9 - Provide a traceability matrix for documenting compliance with the above. Provide a traceability matrix for documenting compliance of the testing procedures. The traceability matrix provides a mechanism for ensuring that each functional requirement is (April 18, 2014) October 23,

10 tested and that each item to be tested has been addressed in the specifications. A sample traceability matrix applicable to an emergency vehicle preemption project is shown as part of Form and is available on the OTO Forms web page at The form may be modified as necessary. The traceability matrix will be included in the contract documents for use during construction. The completed traceability matrix will include the results of the test and any necessary work to address failures during the test and will be included in the project construction records. SEA Item #10 - Provide change management control. Provide a description of the change management control. Describe what changes were made during project development, how changes were accommodated, and how change orders will be processed and managed during construction, including identifying necessary approvals. In many cases standard procedures used by the agency will incorporate many of these items. This item requires documentation of changes in design, construction, and operations. SEA Item #11 - Provide a Maintenance Plan and a funding analysis for the maintenance, operation and funding of the system after completion. This includes an analysis of cost, personnel, and anything further required to maintain and operate. Provide a Maintenance Plan and a funding analysis for the maintenance and operation of the system after completion. This includes an analysis of cost, personnel, software, utilities and anything further required to maintain and operate the system, typically on an annual basis. Examples of this item are available on the OTO website. SEA Item #12 - Provide documentation for revising the Regional ITS Architecture. Provide documentation for revising the Regional ITS Architecture after project construction. Contact the appropriate MPO for preferred or required formats for submitting this information Additional Requirements The Programmatic Agreement for ITS Systems Engineering Analysis and the Ohio Federal-Aid Highway Program Stewardship and Oversight Agreement between ODOT and FHWA establishes FHWA involvement on ITS projects. It is anticipated that the SEA documentation will be prepared by the local agency or its consultant, for submission to the appropriate ODOT District, to be forwarded on to OTO. For ODOT projects, it is anticipated that the documentation will be prepared by the ODOT District for submittal to OTO. Local agencies shall submit all appropriate documents to the appropriate ODOT District for review and approval per the existing project administration procedures. OTO will then coordinate with and forward submittals to FHWA per the Federal-aid Highway Program Stewardship and Oversight Agreement. In addition, when the project is covered by a Regional ITS Architecture, the as-built Project Level ITS Architecture with any modifications noted, shall be submitted by the local agency to the appropriate MPO for updating the Regional ITS Architecture. Contact OTO for preferred documentation formats. Forms and provide sample documents that can be used, including a simplified form for Emergency Vehicle October 23, 2002 Revised April 18, 2014

11 Preemption projects. These forms are available on the OTO Forms web page at The forms may be modified as necessary. For signalized intersections within about 200 feet of a highway rail intersection, additional work may be needed. A simplified form for Railroad Preemption projects is available from the OTO upon request. Project documentation shall be retained by the District in their project files. For Low-Risk ITS Projects, a copy of the completed SERF shall be kept in the project files. For Low-Risk or Exempt Projects that affect multiple agencies, a copy of the Operations and Management Agreement shall be kept in the project files. For High-Risk ITS Projects, a project-specific Systems Engineering Analysis shall be kept in the project files. ODOT shall designate the ITS applicability of every Federal-aid project on its web-based application for project management (currently Ellis). See Section for Ellis requirements. If any uncertainty exists regarding design requirements, standards or forms, or other ITS requirements, the project sponsor should contact the District Ellis Requirements for ITS Projects ITS projects shall utilize one of the two following Ellis Project Report Codes as appropriate to document progress toward completion of the required CFR 940 documentation. The report codes should be created and updated throughout the project beginning at the time the project is scoped. During PS&E approval of a project, Ellis will be referenced to determine if documentation is required. If an ITS project does not have the proper documentation, authorization for funding of the project could be delayed at PS&E. Ellis Report Codes: CFR 940 Exempt ITS Project CFR 940 Low-Risk ITS Project CFR 940 High-Risk ITS Project N/A Revised April 18, 2014 October 23,

12 Intentionally blank October 23, 2002 (April 18, 2014)

13 1303 FREEWAY MANAGEMENT SYSTEMS ON ODOT-MAINTAINED HWYS General A primary goal of the Freeway Management System (FMS) is to provide reliable and timely travel information. This shall be achieved through the provision of route and segment-based travel times. Valid travel times are to be provided in real time, providing easily accessible information about delays. Information dissemination will be accomplished using a variety of methods including: OHGO.com Dynamic Message Signs (DMS) Highway Advisory Radio (HAR) Ohio 511 telephone number Radio and television broadcasts (private-sector leveraging FMS information) It is the intended that ODOT s statewide FMS deployment will provide full coverage of six of the metropolitan areas with full instrumentation and communication to a central Traffic Management Center (TMC), in accordance with the Regional Architecture prepared by the MPO in cooperation with ODOT and FHWA. The Regional Architectures are defined in the Detailed Project Plans, prepared under the direction of these same agencies. In addition to the information provided herein, the ODOT Office of Traffic Operations (OTO) has developed a standard set of Special Provisions including most items that are normally used in the ITS infrastructure throughout the State. During the design phase of projects, design consultants may contact the OTO for the most recent set of Special Provisions or check online at Traffic Management Center (TMC) The ODOT s Statewide Traffic Management Center (TMC) operates traffic management and traveler information systems on Ohio s Interstates, other freeways, expressways and state highways. The mission of the TMC is to increase transportation safety, reduce congestion, and increase efficiency on Ohio s state highways. Housed in ODOT s Central Office building, the TMC monitors traffic in each of the State s major metropolitan areas including Akron/Canton, Cincinnati, Cleveland, Columbus, Dayton/Springfield, and Toledo. TMC operators can control cameras and post traveler information messages to ODOT s Dynamic Message Signs, Highway Advisory Radio, and to the OHGO website. The TMC operators can also act as liaisons between the Freeways Service Patrol and various other public agencies that respond to the scenes of vehicle incidents Closed Circuit Television (CCTV) CCTV cameras provide an opportunity for congestion and incident management verification. FMS areas function very efficiently with the use of CCTV cameras. They provide views of the highway system that can only be otherwise obtained by first hand viewers and provide a great amount of information to Traffic Management Center (TMC) operators. CCTV camera placement is expected to be at approximately 1-mile spacing to provide full coverage of the freeways. Cameras are usually located at interchanges which afford an opportunity to view not only the freeway mainline, but the ramps and cross routes as well. The viewing angle of the camera shall give preference to the freeway mainline with arterial coverage included to the extent possible. CCTV camera placement is covered in each FMS project design guidelines, which are available from the Office of Traffic Operations (OTO) upon request. All CCTV cameras installed for use in the FMS shall be of the pan-tilt-zoom type. General area CCTV cameras shall be of the dome-type. CCTV cameras used in tunnels, trenches, or other areas where the cameras may have a high probability of being succumbed to moisture-spray Revised January 17, 2014 October 23,

14 from vehicles shall be directional bullet style cameras with wipers and/or thermal imaging cameras. The OTO shall be contacted for the latest specification for each type of camera. The CCTV cameras are also in demand for use by local jurisdictions and other agencies, the media, and the public (via the internet). The central video control system will be designed to accommodate external feeds of camera images, both streaming and static. In cases where a noninternet connection is used to access video feeds from the TMC, external users of the video will be required to sign a CCTV License Agreement. There shall be no fee for use of ODOT FMS video although the users must arrange for their own communication pathway to the TMC video server. Information about operation of the CCTV cameras by TMC personnel, as well as remote access by authorized users, will be available from OTO. This will include general rules for routine use of the cameras such as limitations on zoom functions during incidents and scenes involving solely private property. When CCTV cameras are being manipulated or are zoomed in to assist with an incident, the video signal from the server is generally blocked. It may be necessary to disable the video feed manually, or it may be an automatic software function, depending on the FMS software version. Generally, CCTV camera images will be recorded for a period of three days and then automatically overwritten Communication FMS communication systems are critical to successful operation. ODOT has determined that the most effective (high-level) system requirement for FMS communications is to mimic the ODOT network. Therefore, field device communications shall use Ethernet and other devices compatible with equipment routinely used by ODOT. The FMS network shall be separate from the ODOT network although there will be connectivity between the two systems. ODOT network interoperability is coordinated with the Network Operations Center of the ODOT Division of Information Technology (DoIT). Fiber optic cable is the medium of choice although many last-mile and point-to-point applications require wireless or other forms of wire-line communications (e.g. T-1, POTS, Coax, CDMA). Communications redundancy in the field will be limited until additional funding is available or new techniques are developed. TMC operational redundancy shall be provided via a backup TMC. To facilitate standardized communication protocols, NTCIP-compliant devices will be used when possible. Field device communication represents a significant cost in the design, deployment and operation of an FMS. ODOT systems will use a hybrid of Ethernet-based fiber optic and wireless communications to maximize bandwidth for the least cost to support the field infrastructure. Connectivity is desired for remote operations and pushing video and data to a number of external users/agencies. The central software system shall be designed to provide flexibility in the provision of access by others outside the TMC and the FMS/ODOT networks. An internet connection to the FMS network will be the most effective means of providing access to the system. When designing plans that include fiber optic cable as a communication method, figures shall be included to show how the fiber optic cable is to be terminated / spliced at each location. These figures include one figure per field cabinet (e.g., Figure : Node Cabinet Assembly), one figure per splice enclosure (e.g., Figure : Underground Splice Enclosure), and one figure showing a high-level splicing scheme for the entire project (e.g., Figure : Fiber Backbone Splice Chart), and a high-level device communication plan for the entire project (e.g., Figure : ITS Device Communication Diagram) Dynamic Message Signs (DMSs) Dynamic Message Signs (DMSs) are a key component to an effective FMS. The installation of DMSs can help to reduce traffic congestion during incidents and will help to provide travelers with real time traffic information October 23, 2002 Revised January 17, 2014

15 DMSs shall be installed at strategic locations on urban freeways to advise drivers of incidents and warn of congestion or stopped traffic. Generally, no alternate route will be specified, although the messages on the signs may suggest the use of alternate routes. When no particular incidents are worthy of mention, the default message, with travel time through key segments of the urbanized area, shall be displayed. Messages for DMSs shall be chosen from a DMS message library unless a different message is truly needed. If a different message is needed it shall be created by the appropriate party. When resources limit full deployment of DMSs in accordance with Detailed Project Plans and FMS design guidelines, first priority will be given to sites on routes inbound to a central business district, deferring outbound DMSs to subsequent phases. The design plans must be in accordance with the Detailed Project Plan Vehicle Detection For an FMS, the conventional form of vehicle detection is side-fired radar with algorithms which manipulate the detector to develop speed, volume and occupancy or density. This data can be used for both the calculation of travel times and incident identification. In many states, the use of fixed-point detection for incident detection has proved to be costly and ineffective. Various types of detectors have been implemented with varying degrees of success. Numerous installations are likely to use other technologies such as video image detection, and acoustic detection for acquiring traffic flow information. The current practice for obtaining travel-time information is through the use of Doppler radar along urban Interstate and Interstate look-alike routes as well as cellular phone GPS data for all other types of routes. Various technologies are available to provide travel times. The incidents are verified and travel times can be corroborated using CCTV Highway Advisory Radio (HAR) Highway Advisory Radio (HAR) is an element to the FMS which, if utilized properly, can provide a great public benefit. The HAR system provides near-real time information on the freeway system during operational hours. When systems are unattended, other valuable traveler information will be broadcast such as construction activities on-going or special events that may impact traffic. It is essential that the HAR is reliable 24/7 and provides accurate, timely information. Similar to DMS system, when no particular incident or congestion-related information is applicable, the HAR will provide an accurate and timely announcement of that fact. The HAR shall be automated so that when travel times increase a pre-determined amount for a particular section of roadway, the HAR will provide travel-time information for that particular section of roadway only. More information on HAR is available in Section Travel Time Travel times are calculated along segments of Ohio roadways using various sources of speed data. These travel times are then displayed on DMS, HAR, 511, and the OHGO website as a means of communicating to the public the expected travel time to and from select destinations. All travel time calculations are generated by the Office of Traffic Operations (OTO) Road Weather Information System (RWIS) A Road Weather Information System (RWIS) is comprised of Environmental Sensor Stations (ESS) in the field, a communication system for data transfer, and central systems to collect field data from numerous ESS. These stations measure atmospheric, pavement and/or water level conditions for flood information. Central RWIS hardware and software are used to process observations from ESS to develop forecasts, and display or disseminate road weather information in a format that can be easily interpreted. RWIS data are used by road operators and maintenance staff to support decision making. There are three types of road weather information: atmospheric data, pavement data and floodwater level data. Atmospheric data include air temperature and humidity, visibility distance, wind speed and direction, precipitation type and rate, cloud cover, tornado or waterspout Revised January 17, 2014 October 23,

16 occurrence, lightning, storm cell location and track, as well as air quality. Pavement data include pavement temperature, pavement freezing point, pavement condition (e.g., wet, icy, flooded), pavement chemical concentration, and subsurface conditions (e.g., soil temperature). Water level data include stream, river and lake levels near roads, as well as tide levels (i.e., hurricane storm surge). Transportation managers utilize weather warning systems and websites to disseminate road weather information to travelers in order to influence their decisions. This information allows travelers to make choices about travel mode, departure time, route selection, vehicle type and equipment, and driving behavior. In Ohio, RWIS provides information on current conditions and assists with forecasting for snow, ice control and removal, flooding, etc. Information is available at the OHGO website ( combined with forecasts provides District maintenance staff with the best information for snow and ice control. This information allows Districts to most efficiently allocate resources including snow plows, and salt and brine applications Ramp Metering Ramp Metering is another key FMS component. Its basic function can help to greatly reduce traffic congestion in FMS areas and result in more efficient travel. There are several modes of ramp meter operation, including the following: Corridor-based Traffic-Responsive (using mainline and ramp traffic flow data from upstream and downstream stations). Local Traffic-Responsive (activated by mainline congestion or speeds at the ramp location). Pre-timed (Time-of-Day). Manual (locally through controller front display). Downloadable (from the TMC) ramp timing changes. Properly timed and operating ramp meters help the mainline to maintain steady flow, resulting in less mainline rear-end crashes, while adding a few less severe crashes on ramps. Ramp Metering is currently provided in the following metropolitan areas: Columbus Cincinnati District 6 currently operational with new installations underway District 8 currently operational with new installations underway Ramp Metering may be provided in the following metropolitan areas as conditions warrant: Toledo District 2 Akron/Canton District 4 Dayton District 7 Cleveland District 12 Special design considerations are needed for non-standard ramps or ramps with inadequate storage capacities or acceleration lengths. Decision flowcharts are provided in the Ramp Metering Guidelines (available upon request from the ITS Section of ODOT Office of Traffic Operations) as an aid to designers implementing ramp metering in nonstandard situations. Nonstandard ramps will be metered on a case by case basis, although system-wide metering is the intent. Ramp Design Guidelines which provide law enforcement pads are included in the ODOT L&D Manual. In some cases it will be necessary to provide surveillance of the ramp meters through CCTV cameras or other means to ensure congestion is not aggravated by the metered condition. More information on Ramp Metering signals is available in OMUTCD Chapter 4H Traffic Incident Management Traffic incident management is addressed in Chapter October 23, 2002 Revised January 17, 2014

17 1343 SPECIFICATIONS ODOT specifications for the furnishing and installation of Intelligent Transportation System (ITS) equipment are contained in the following C&MS sections, Supplemental Specifications and Supplement. Also, see Chapter 443 for information about specifications related to traffic signal equipment. 631 and 731 Sign Lighting and Electrical Signs Supplemental Specifications 804 and 904 address Fiber Optic Cable and Components. Supplemental Specification 809 addresses Intelligent Transportation System (ITS) Devices and Components. Supplement 1077 covers the prequalification procedure for Dynamic Message Signs. Information on the C&MS may be viewed on-line at Book.aspx; and information on Supplemental Specifications and Supplements may be viewed at entalspecificationsandsupplements.aspx. Revised January 16, 2015 October 23,

18 Intentionally blank October 23, 2002 (January 16, 2015)

19 1396 FORMS INDEX The following forms are available only on the Office of Traffic Operations (OTO) website at ITS Form As noted in Subsection , Form may be used and modified as necessary for completing the Systems Engineering Analysis ITS Form for Emergency Vehicle Preemption (EVP) As noted in Subsection , Form is an abbreviated Minor ITS Form available for use in documenting the SEA for Emergency Vehicle Preemption projects Systems Engineering Review Form (SERF) As noted in Subsection , Form may be used for a project to gain programmatic approval of meeting the requirements set forth under 23 CFR 940. (January 16, 2015) October 23,

20 Intentionally blank October 23, 2002 (January 16, 2015)

21 1397 TABLES INDEX Exempt, Low-Risk and High-Risk ITS Projects As noted in Subsection , Table presents examples of Exempt, Low-Risk or High-Risk ITS projects ITS User Services Table presents a list of all the ITS User Services available Regional ITS Architecture in Ohio As noted in Subsections , , and , Table presents a list of the locations with MPO s in Ohio, and the MPO websites. (January 16, 2015) October 23,

22 Intentionally blank October 23, 2002 (January 16, 2015)

23 Table Exempt, Low-Risk and High-Risk ITS Projects Exempt Low-Risk High-Risk Changes and/or upgrades to an existing traffic signal system, including signal timing revisions, additional phases (vehicle or pedestrian) or detector installation. Routine maintenance and operation of an existing ITS system. Expansion of an existing traffic signal, ITS or freeway management system (FMS) that does not change or add to the original needs and requirements of the system. This type of project does not change any existing hardware, software or interfaces. It simply adds equipment (DMS, DDMS, HAR, CCTV, RWIS, etc.), software, locations or intersections to an existing system. The new equipment and software must be compatible with the existing. Installation of an isolated traffic signal. This is a single traffic signal, not connected to any type of external signal control, nor likely to be connected in the future due to its isolation. Installation of traffic signals which are part of a Time-Based Coordinated system. Installation of traffic signals which are part of a hardwired or wireless interconnected system that is locally controlled, i.e. where the timing patterns are controlled by the local controller and not by centrally controlled software. Installation of cameras that are not functionally integrated into other types of systems; for example, cameras solely for the purpose of traffic data collection or surveillance cameras. Closed loop arterial traffic signal system. Centrally controlled arterial traffic signal system. Highway Rail/Traffic Signal pre-emption. Traffic signal system with Emergency Vehicle Pre-emption. Traffic signal system with Transit Priority. Ramp Meter system. Adaptive Traffic Signal Control system. New freeway management systems (FMS). Traffic signal systems that requires integration with other systems, e.g. FMS or RWIS. Ramp meter systems that require integration with adjacent traffic signal system(s). Regional traffic signal system (as opposed to an arterial traffic signal system) that as the potential to affect geographic areas outside of the maintaining agency. Regional transit systems. Any Low-Risk project that provides additional functionality than what is covered in the approved Functional Requirements document for that project category. Any project that requires new or unproven hardware, software or interfaces. Any project for which functional requirements and operations & management procedures have not been documented. Any project not considered Exempt or Low-Risk under the Programmatic Agreement. (January 16, 2015) October 23,

24 Table ITS User Services To find detailed information relating to each of the User Services below, visit and select User Services from the navigation bar at the top of the screen. Travel and Traffic Management 1.1 Pre-trip Travel Information 1.2 En-route Driver Information 1.3 Route Guidance 1.4 Ride Matching And Reservation 1.5 Traveler Services Information 1.6 Traffic Control 1.7 Incident Management 1.8 Travel Demand Management 1.9 Emissions Testing And Mitigation 1.10 Highway Rail Intersection Public Transportation Management 2.1 Public Transportation Management 2.2 En-route Transit Information 2.3 Personalized Public Transit 2.4 Public Travel Security 3.1 Electronic Payment Services Electronic Payment Commercial Vehicle Operations 4.1 Commercial Vehicle Electronic Clearance 4.2 Automated Roadside Safety Inspection 4.3 On-board Safety And Security Monitoring 4.4 Commercial Vehicle Administrative Processes 4.5 Hazardous Material Security And Incident Response 4.6 Freight Mobility Emergency Management 5.1 Emergency Notification And Personal Security 5.2 Emergency Vehicle Management 5.3 Disaster Response And Evacuation October 23, 2002 (January 16, 2015)

25 Table ITS User Services (Continued) Advanced Vehicle Safety Systems 6.1 Longitudinal Collision Avoidance 6.2 Lateral Collision Avoidance 6.3 Intersection Collision Avoidance 6.4 Vision Enhancement For Crash Avoidance 6.5 Safety Readiness 6.6 Pre-crash Restraint Deployment 6.7 Automated Vehicle Operation 7.1 Archived Data Information Management 8.1 Maintenance And Construction Operations Maintenance and Construction Management (January 16, 2015) October 23,

26 Table Regional ITS Architecture in Ohio Akron/Canton Regional ITS Architecture: MPO: AMATS (Akron Metropolitan Area Transportation Study) MPO Web site: MPO: SCATS (Stark County Area Transportation Study) MPO Web site: Cincinnati/Northern Kentucky Regional ITS Architecture: MPO: OKI (Ohio-Kentucky-Indiana Regional Council of Governments) MPO Web site: Cleveland Regional ITS Architecture: MPO: NOACA (Northeast Ohio Areawide Coordinating Agency) MPO Web site: Columbus Regional ITS Architecture: MPO: MORPC (Mid Ohio Regional Planning Commission) MPO Web site: Dayton/Springfield Regional ITS Architecture: MPO: MVRPC (Miami Valley Regional Planning Commission) MPO Web site: MPO: CCSTCC (Clark County-Springfield Transportation Coordinating Committee) MPO Web site: Toledo Regional ITS Architecture: MPO: TMACOG (Toledo Metropolitan Area Council of Governments) MPO Web site: Youngstown Regional ITS Architecture: MPO: Eastgate (Eastgate Regional Council of Governments) MPO Web site: October 23, 2002 (January 16, 2015)

27 1398 FIGURES INDEX Project Development Process (PDP) As noted in Section , Figure is a graphical representation of the Project Development Process (PDP) Fiber Optics Termination Diagram (Node Cabinet Assembly) As noted in Section , Figure is a sample representation of what shall be included in plan sets for all fiber optic design on ODOT projects dealing with Intelligent Transportation Systems (ITS) or Signal Systems Fiber Optics Termination Diagram (Underground Splice Enclosure) As noted in Section , Figure is a sample representation of what shall be included in plan sets for all fiber optic design on ODOT projects dealing with Intelligent Transportation Systems (ITS) or Signal Systems Fiber Optics Termination Diagram (Fiber Backbone Splice Chart) As noted in Section , Figure is a sample representation of what shall be included in plan sets for all fiber optic design on ODOT projects dealing with Intelligent Transportation Systems (ITS) or Signal Systems ITS Device Communication Diagram As noted in Section , Figure is a sample representation of what shall be included in plan sets for all fiber optic design on ODOT projects dealing with Intelligent Transportation Systems (ITS) or Signal Systems. (January 16, 2015) October 23,

28 Intentionally blank October 23, 2002 (January 16, 2015)

29 Figure Project Development Process (PDP) (January 16, 2015) October 23,

30 Figure Fiber Optics Termination Diagram (Node Cabinet Assembly) October 23, 2002 (January 16, 2015)

31 Figure Fiber Optics Termination Diagram (Underground Splice Enclosure) (January 16, 2015) October 23,

32 Figure Fiber Optics Termination Diagram (Fiber Backbone Splice Chart) October 23, 2002 (January 16, 2015)

33 Figure ITS Device Communication Diagram (courtesy of HNTB, Ohio) (January 16, 2015) October 23,

34 Figure ITS Device Communication Diagram (continued) October 23, 2002 (January 16, 2015)