Active Traffic Management (ATM) Implementation and Operations Guide

CHAPTER 3. DESIGN CONSIDERATIONS

The design of an active traffic management (ATM) system can be a complex endeavor. An agency needs to consider the various features and processes related to design when moving forward with ATM projects. These features and processes include the Concept of Operations (ConOps); requirements development; physical design; performance-based practical design; technology, procurement, and testing; and impact of connected and automated vehicles (CAVs) on ATM. The following sections are included in this chapter:

• Concept of Operations. This section presents the topic of a ConOps and its importance in the development and implementation of ATM projects within a jurisdiction.
• Requirements. This section provides an overview of identifying system requirements for an ATM strategy or deployment.
• Design Elements. This section provides an overview of the physical design elements that are essential to successful operations of ATM strategies and that agencies should consider.
• Performance-Based Practical Design. This section provides an overview of the concept of performance-based practical design (PBPD), highlighting case studies demonstrating PBPD through the analysis of ATM strategies.
• Technology, Procurement, and Testing. This section presents the design aspects of the technological components of ATM strategies, including procurement and testing of the technology and integration with existing systems.

3.1 CONCEPT OF OPERATIONS

A ConOps addresses many important planning-level questions and is among the essential early steps of the systems engineering process. This stage of the project establishes needs; documents existing systems, stakeholder roles, and responsibilities; identifies priority ATM functions; and identifies longer-term requirements (such as maintenance) that can be integrated into budgeting, procurement, and implementation activities.⁽⁴⁵⁾ The ConOps should build off the components in the regional intelligent transportation systems (ITS) architecture; however, in some cases, the ConOps provides important input to updates needed for the regional ITS architecture. The ConOps also provides valuable input to the field and software design needs, which are addressed in later sections of the guidebook.

It is essential to get broad stakeholder input as part of this process because ATM likely affects multiple stakeholders. Part of the ConOps process is to address key decisions that need to be made, such as enforcement, coordination across modes (freeway, arterial, and transit), long-term funding needs, and ability to leverage existing systems. The ConOps creates a basis for defining specific user requirements, system functional requirements, and more detailed design in later phases of the system development process. There is some flexibility in terms of level of detail and items included as part of a ConOps for ATM. A ConOps typically includes the following elements and sections, although States and regions are encouraged to view these typical elements as a starting point rather than a prescriptive template.

For more information on developing a ConOps, visit FHWA's Systems Engineering Guidebook for ITS (https://www.fhwa.dot.gov/cadiv/segb/files/segbversion3.pdf).

Scope

Within the ConOps, the scope section provides a brief description of the planned ATM project and its overall purpose.⁽⁴⁶⁾ It should include an overview of the system that will be built and describe the area the system will cover. It briefly describes the purpose of the system, highlights major goals and objectives to be achieved (and what specific issues will be addressed through ATM), identifies the intended audience of the document, and sets the boundaries for the system. This section also describes an overarching vision for ATM in a particular region or for a specific corridor. Multiple stakeholders should be involved in defining the scope, goals, objectives, and vision for the ATM system.⁽⁴⁷⁾

For the initial ATM deployment in Seattle, Washington State Department of Transportation (WSDOT) included additional information in the ConOps. The document included background information on ATM so that partnering agencies would be familiar with the concept.⁽⁴⁸⁾ Specific sections included a description of each of the operational strategies that were included along with major goals and objectives for the project. For each individual ATM strategy to be implemented, the document provided a description of the strategy, early applications either in the United States or overseas, and photographs to illustrate the concept. Additional background information that could be beneficial to the intended audience of the ConOps might include a description of a ConOps⁽⁴⁹⁾; the project need⁽⁵⁰⁾; inclusion of the project vision, mission, and goals; and project stakeholders and intended audience.⁽⁵¹⁾

The ATM ConOps scope should include an overview of the ATM project and the specific purpose for the ATM strategies, including which specific regional challenges the strategies are intended to address. Typical regional needs might include congestion, safety, travel choices, and travel reliability.

Reference Resources

This section of the document lists all the references used to develop the ATM ConOps as well as other sources of alternative information relevant to the system's development or refinement. These might include business processes, regional concepts of transportation operations plans, long-range transportation management plans, regional ITS architectures that may impact ATM system development, concept feasibility, and alternative analyses studies. WSDOT included additional background information related to ATM, specifically the original Federal Highway Administration (FHWA) report on ATM that introduced the concept to the United States.⁽⁴⁸⁾ Pennsylvania Department of Transportation (PennDOT) included supporting references related to the need for transportation systems management and operations (TSMO) and ATM, website links, and related ConOps for active transportation and demand management (ATDM) implementation.⁽⁵¹⁾ Virginia Department of Transportation (VDOT) included a link to State government codes that would have an impact on the application of variable speed limits along with background information on the VDOT Smart Travel Program Plans.⁽⁴⁹⁾

User-Oriented Operational Description

This section contains the ATM strategies and tactics to be employed using the system, policies and constraints impacting how the system operates, which personnel will be using the system and how, interactions among stakeholders, and sequence of actions taken in a response. It also describes the various stakeholders and their roles and responsibilities. A key focus of this section is to describe the ATM system from various user vantage points. This information could include operational processes and roles of all the project stakeholders, including State/freeway operations traffic management, local traffic management, transit operators, traffic incident responders, and travelers themselves, among others. WSDOT provided specific details for each ATM application included in the ConOps, presented the overall proposed system, described user classes and stakeholder needs, and presented the operational goals and objectives for ATM in the region.⁽⁴⁸⁾ PennDOT took a slightly different approach and included specific descriptions of the system from each of the stakeholder groups, including the State, local municipalities, the regional metropolitan planning organizations (MPOs), FHWA, the local county, and transit, to name a few.⁽⁵¹⁾ Additionally, PennDOT included a description of the current system in operation along I-76 to set the stage for how the ATM system would need to integrate with what was already in place.

User-oriented operational descriptions of each ATM strategy are essential to the overall ConOps. These descriptions provide details about the proposed systems, the anticipated users, how the users will interact with the strategies, and what organizational and system-specific goals and objectives met by deploying the strategies.

Operational Needs

This section describes, at a high level, what stakeholders need and want the ATM system to do, including specific problems on a corridor that need to be addressed (such as recurring bottlenecks or safety issues); specific functions that technology can support; and operational needs. ATM operational needs could include infrastructure and tools to support project objectives, new processes, improved coordination among partnering agencies, addressing specific bottlenecks or safety issues on a specific segment of roadway, and a range of other user-specific needs. Identifying and organizing needs helps to provide a level of traceability through the different stages of more detailed design. This approach also allows an agency to map requirements and design elements back to specific needs, which helps to ensure that the system is meeting the identified objectives. VDOT described the operational needs in two contexts: during construction and after construction.⁽⁴⁹⁾ WSDOT described the operational needs that were not currently being met by the system as well as the needs for staffing, data support, and a communications structure.⁽⁴⁸⁾ PennDOT presented current technologies in use that would require enhancements to support the ATM implementation.⁽⁵¹⁾

Operational needs for ATM should include a description of the users who will benefit from the ATM deployment, existing operations systems and management that will be instrumental in the ATM deployment, and stakeholders that have a vested interest in the ATM project and its overall successful operations.

System Overview

This section gives a general description of what the ATM system will do, when, and how. It identifies and describes regional and/or corridor goals and objectives for the system, as well as what information is needed for a decision and from where and how frequently this information is gathered (i.e., interfaces). The ATM system overview also should include a project-level architecture, showing the relationships of the different system components, how they will interface with existing systems and stakeholder agencies, and what information will be shared among new and legacy systems. High-level schematic diagrams can show relationships among systems, while more detailed diagrams can show more specific interfaces and information/data exchanges. WSDOT provided high-level descriptions of the operational features of its ATM system, including the context within the National ITS Architecture; integration with its current ITS infrastructure and programs; major system components; necessary interfaces with external systems; and proposed capabilities and functions of the system.⁽⁴⁸⁾ PennDOT described the proposed strategies and focused on the technology, components, applications, and standards needed for successful implementation of each strategy.⁽⁵¹⁾

The ATM system overview describes overarching ATM considerations, capabilities, functions, and key elements likely to interface, support, or impact the strategies. These elements might include the ITS architecture, external systems, CVs, ICM, communications, data collection and monitoring, tolling, etc.

Operational and Support Environments

This section provides a description of the required physical, operational, and support environments in which the ATM system must operate. It includes information on the facilities, equipment, computing hardware, software, personnel, operational and support procedures, and so forth necessary to operate and maintain the deployed system. In particular, the impact on personnel needs to be considered (e.g., Are new personnel needed to support the new system? Can current personnel be realigned to meet the needs of the new system?). Cost information, even at the planning level, must be identified early in the process. This section should also include some details on longer-term operations and maintenance needs, including life-cycle costs of equipment, operation and maintenance requirements of the new system, new training requirements, and new agreements needed. WSDOT's ATM ConOps included capital costs for ATM elements, as well as estimated operations and maintenance costs for the major components of its initial ATM system.⁽⁴⁸⁾ PennDOT included high-level system costs and factors considered in developing conceptual cost estimates; maintenance costs broken down by component, life cycle, and annual costs per device; general operational costs; and a deployment concept based on early-action, short-term, and long-term implementation of ATM.⁽⁵¹⁾ Additionally, PennDOT provided information on the support environment that would impact and/or be elemental for successful implementation. Information contained in this section included a regional operational research model project, planned arterial enhancements, communications, the regional TMC, enforcement, and public outreach and education.

Operational and support environment information should include system costs for the major ATM elements, operations and maintenance costs, deployment and life cycle information, as well as any impacts agencies need to consider during deployment, including that related to retrofitting on existing facilities, and user and support involvement that may be more complex than that with traditional capital projects.

Operational Scenarios

This section describes how the system will be operated under different circumstances and situations. Scenarios are developed from a user's perspective and might include typical day-to-day operations of the ATM (typical AM and PM commutes), operations during planned events (such as a work zone or a special event that significantly impacts traffic flow and volumes), and incident or emergency conditions (such as severe weather, an incident blocking lanes, or an evacuation). This section should detail how the system would operate, what changes would be necessitated, how agency/responder roles would change, and what information would be communicated to travelers and to agencies. Scenarios should describe, in enough detail, how the system is envisioned to operate, how different systems will interact, how stakeholders will operate and interact with the ATM system, and what the impact or benefit will be to the user on the road. A simulation exercise is a good complement to the operational scenarios; items detailed in this section and others of the ConOps can provide valuable inputs into a simulation. WSDOT included various scenarios (i.e., normal operations, incident situations, work zone/maintenance, and queue spillback) and included a description of the provision of traveler information and anticipated opportunities and constraints of the system.⁽⁴⁸⁾ PennDOT structured the scenarios by ATM strategy and provided information for each on free flow, recurring congestion, lane restriction, weather conditions, complete closure, and nonrecurrent congestion.

ATM operational scenarios should include all of the scenarios under which the strategies will operate—both recurrent and nonrecurrent conditions—and how the operating agency will manage them. The scenarios need to reflect current operations and incorporate new protocols to accommodate the dynamic operations.

Summary of Impacts

This section summarizes key impacts as a result of implementing ATM. This section can also serve as a record of key decisions made for the ATM. Typically, impacts are organized into:

• Operational impacts, such as new data sources, new processes, and new systems.
• Organizational impacts, such as necessary new staff, new training, and new lines of communication among stakeholders.
• Impacts during development, including how current and new systems will operate in parallel, how changeover to the new system will occur, and what stakeholders will expect during development/testing/implementation.

Ohio DOT's draft ConOps for a statewide ATM study, which incorporates all critical elements, is available online (ftp://ftp.dot.state.oh.us/pub/Comm/I-275-SmartLane/ATDM%20Draft%20ConOps/ODOT%20Draft%20ATM%20ConOps%20(9%2015%2016)v3.pdf).

ATM Application: The ConOps document for the WSDOT I-5 project incorporated all of the document elements discussed in this section. Specific items of note that provide ATM-related detail include the operational scenarios, which describe how the ATM strategies will operate along the facility. The operational scenarios document how the dynamic speed limits, dynamic lane use control, queue warning, and dynamic shoulder lanes will operate along both basic freeway segments and managed lanes segments. The scenarios include operations during normal conditions, incident situations, in work zones or during roadway maintenance, and during queue spillback. Traveler information is also discussed along with a summary of anticipated benefits. Opportunities and constraints associated with the proposed ATM system are also included. Each scenario presents visual examples and sign sequencing of the planned overhead sign gantries as well as information on enforcement of the ATM strategy, operations, staffing needs, and maintenance. Active Traffic Management Concept of Operations, Washington State Department of Transportation, 2008, http://www.wsdot.wa.gov/nr/rdonlyres/73ac9a17-6178-4271-b3a9-91911bd1c8c6/0/finalatmconceptofoperations.pdf.

3.2 REQUIREMENTS

Requirements serve as the foundation of any ITS components of an ATM system. Their importance cannot be overstated because an agency uses them to determine what the ATM system must do, and they serve as the benchmark against which an agency will verify that the ATM system was built correctly.⁽⁴⁶⁾ These requirements should include both functional requirements (i.e., what the system is supposed to do) and performance requirements (i.e., how well the system accomplishes its functions). Additionally, an agency should establish environmental and nonfunctional requirements that establish under what conditions the system is required to function to meet its performance goals. An agency should develop a system and subsystem requirements document in preparation for ATM implementation. This document should include the following information to clearly describe the requirements of the proposed ATM system⁽⁴⁶⁾:

• Overview and scope of the system and the specific ATM strategies to be included therein, including full identification; ATM system purpose, goals, and objectives; history of system development, operation, and maintenance; project stakeholders and users; and current and planned operating sites for individual and/or multiple strategies.
• Reference documents needed to support the requirements, including background research, documentation of similar applications in other locations, regional program plans, and other resources.
• All requirements for the ATM system, including functional requirements, performance requirements, interface requirements, data requirements, nonfunctional requirements, enabling requirements, and constraints.
• Verification methods for each requirement of the system, including demonstration, testing, analysis, and/or inspection for the specific environmental requirements under which the ATM strategies should function.
• Supporting documentation that can enhance understanding of the requirements.
• Traceability matrix that traces the requirements to higher-level requirements and user requirements.
• Glossary of terms, abbrs, and definitions.

Requirements are a critical element of procurement documents, such as with a plan, specification, and estimate (PS&E) package prepared for construction or as part of a request for proposals for a design-build project. In these cases, and others, the agency can ensure that the ATM system deployed meets the intended goals and objectives and operational performance.

The development of a safety specification for the ATM control system for English motorways is available online (http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=976B73DDAA3DC7973E2F90B80733D6AF?doi=10.1.1.483.8439&rep=rep1&type=pdf).

3.3 DESIGN ELEMENTS

The general design elements of an ATM application or overall system can be divided into two broad categories: civil and technology. Individual elements within these categories are needed to deliver the complete system. Detailed design documents developed should comprise detailed requirements that should map back to defined functional requirements established in the ConOps. Detailed design documentation varies for the different portions of an ATM system but should include PS&E and detailed requirements and system architecture.

Civil elements of the design include the typical roadway elements such as pavement design, roadway geometrics, pavement markings, striping, structures, gantries, and static signing. Field equipment includes the technology components located along the roadway to monitor and manage transportation within the corridor, the communications network needed to access and integrate the field equipment, and the central equipment necessary to control the field equipment. The field equipment includes closed-circuit television (CCTV) cameras, message signs (dynamic, changeable, variable), detection, lane control signals, ramp meters, highway advisory radios, and other supplemental technologies as defined within the selected ATM strategies.⁽⁵²⁾ The communications network can include fiber-optic cables, wireless radio links, leased communication lines, and in some unique cases, cellular links to remote equipment.

As with other ITS-related systems, central equipment includes communications and network components located within the operations center that integrate all the field equipment and provide the infrastructure to operate the technology installed in the field. This equipment includes an array of racks, servers, the local area network, and interconnections between these elements. Table 13 presents a summary of the ATM strategies as presented previously along with the possible civil and technology design components associated with their implementation and operation. It is important to note that software is a required element for each strategy and is critical to an effective delivery of the defined solution. The following sections provide information on some of these more critical design elements and how agencies should consider these elements when implementing ATM strategies.

ATM strategies require both civil elements as well as technology elements such as communication, network components, and field equipment. The technology and software elements are critical elements in all applications as they support real-time dynamic operations, which is a cornerstone of ATM strategies.

Table 13. Possible ATM design elements by strategy.

Core Design Element	Adaptive Ramp Metering (ARM)	Adaptive Traffic Signal Control (ATSC)	Dynamic Junction Control (DJC)	Dynamic Lane Reversal (DLR)	Dynamic Lane Use Control (DLUC)	Dynamic Shoulder Use (DShL)	Queue Warning (QW)	Dynamic Speed Limit (DSpL)	Dynamic Merge Control (DMC)
CIVIL ELEMENTS Overhead gantry and/or side-mounted sign; hybrid			X	X	X	X	X	X	X
CIVIL ELEMENTS Static signage	X		X	X	X	X	X	X	X
CIVIL ELEMENTS Interchange geometrics	X		X	X	X	X			X
CIVIL ELEMENTS Pavement markings			X	X		X			X
CIVIL ELEMENTS Emergency pull-offs						X
TECHNOLOGY ELEMENTS Signal controllers	X	X
TECHNOLOGY ELEMENTS Control software	X	X	X	X	X	X	X	X	X
TECHNOLOGY ELEMENTS Detection	X	X	X	X	X	X	X	X	X
TECHNOLOGY ELEMENTS Closed-circuit television cameras			X	X	X	X	X	X	X
TECHNOLOGY ELEMENTS Controller upgrades	X	X
TECHNOLOGY ELEMENTS Communication	X	X	X	X	X	X	X	X	X
TECHNOLOGY ELEMENTS Lane control signals			X	X	X	X		X	X
TECHNOLOGY ELEMENTS Access control system to prevent wrong-way movements				X
TECHNOLOGY ELEMENTS Enhanced corridor lighting			X	X	X	X	X	X	X
TECHNOLOGY ELEMENTS Overhead warning beacons				X			X
TECHNOLOGY ELEMENTS DMSs			X	X	X	X	X	X	X

Geometric Design

Agencies need to assess interchange geometrics when implementing such ATM strategies as adaptive DRM, DJC, or DLUC. For example, ramp modifications may be necessary to accommodate additional capacity for ramp metering strategies. Additionally, ramp modifications and merges at the interchange may be required to accommodate lane configurations for DShL, depending on whether the shoulder use runs through the interchange or traffic must exit at a ramp. The specific operational option can impact ramp bridge widths, ramp or mainline pavement markings, retaining walls under bridges, and other geometrics of the interchange. Designing an ATM system that will minimize geometric changes at interchanges is recommended to minimize construction costs of the system.

The use of the shoulder as a travel lane introduces additional civil design requirements of the ATM system. Shoulder use can be implemented on either shoulder of the roadway but is not recommended for both at the same time. Design elements of any ATM strategy that may have a fundamental impact on the facility should include pavement and signing designs and general design requirements that must be satisfied prior to implementation, including controlling criteria and minimum American Association of State Highway and Transportation Officials (AASHTO) values.⁽²⁴⁾ These include but are not limited to:

• Design speed.
• Lane width.
• Shoulder width.
• Horizontal alignment.
• Superelevation.
• Vertical alignment.
• Grade.
• Stopping sight distance.
• Cross slope.
• Vertical clearance.
• Lateral offset to obstruction.
• Structural capacity of bridges.⁽²⁴⁾

With DShL deployments, an agency may choose to install a small emergency refuge area beside the shoulder. These areas, spaced at periodic intervals, provide motorists a place to pull out of the shoulder traffic in the event of an incident. However, these pull-off areas do not need to meet the same pavement requirements as the shoulder since vehicles are not using them as a travel lane.

Emergency pull-off areas or emergency refuges (also noted as turnouts) provide a safe location for motorists who are experiencing some kind of emergency to remove themselves from the flow of traffic. These areas should be large enough to accommodate vehicles experiencing mechanical failure as well as those involved in a collision. Additionally, they can be used by law enforcement or emergency vehicles, if necessary. These pull-off areas should be at least 16 ft wide and long enough to provide adequate space for whatever purpose they need to serve.⁽²⁴⁾ The spacing between the emergency pull-offs is largely determined by the availability of space and the anticipated demand based on the roadway characteristics. Emergency pull-offs can also be co-located with maintenance pull-off areas to cut down on required space and construction costs.

Geometric design elements need to be carefully assessed when developing ATM strategies. For example, agencies need to decide how to handle dynamic shoulder lanes at interchanges, whether they want to construct emergency refuge areas, or whether there is sufficient storage on ramps to handle queues from adaptive ramp metering.

Infrastructure Design

ATM strategies can present unique challenges with infrastructure design. For example, shoulder pavement is not designed to the same specifications as general-purpose lanes in many locations across the country. This situation presents a challenge if an agency would like to implement DShL. If more traffic is going to utilize the shoulder as a travel lane, improvements to the shoulder pavement may be needed. The structural and geometric design of the shoulder should be compared to that of a travel lane. The following sections provide discussion on specific design features that may be impacted by the deployment of ATM strategies along a facility.

Shoulder Pavement

Shoulder pavement should be able to handle significant traffic if an agency plans on implementing DShL. As such, rebuilt shoulders may be necessary to meet minimum acceptable shoulder design, while striking a balance between keeping the shoulder in its current condition or fully reconstructing it to meet general-purpose lane standards. Costs would certainly play a role in the development of a project. If a region is going to embrace DShL as a matter of policy, then there should be some consideration given to incorporating design standards into future reconstruction/resurfacing that would prepare the shoulder for future use as a lane. This would be much more cost effective than having specific contracts to go back and reconstruct the pavement.

If agencies considering DShL do not plan on replacement or reconstruction of a new shoulder for the installation, they will need to secure a design exception from FHWA ⁽²⁴⁾. This is the same guidance given to agencies converting a full-width shoulder to a high occupancy vehicle (HOV) lane as a lower-cost treatment for congested corridors. Clearly, those vehicles allowed to use the shoulder will impact the required pavement structure. If heavy vehicles present a structural challenge, an agency may prohibit them from using the shoulder.

Infrastructure design elements need to be carefully assessed when developing ATM strategies. For example, allowing traffic to operate on the shoulder may impact traditional design features such as vertical clearance, pavement, drainage, lateral offset to obstruction, and stopping sight distance, which may require design exceptions prior to construction.

Fixed Objects

The implementation of ATM strategies may impact the clear zone, either through the installation of additional roadside equipment (e.g., shoulder-mounted signage) or the proximity of moving traffic to fixed objects. For example, fixed objects may be within the clear zone if DShL, DLU, or DLR is in operation, and if drivers leave the roadway, they have a higher chance of striking an object before recovering. Thus, agencies will want to ensure that new objects are outside the clear zone, remove fixed objects if possible, relocate them beyond the clear zone, or shield them with barriers if they are in a place where they are likely to be struck.⁽²⁴⁾

Vertical Clearance

Typically, the deployment of ATM-related strategies may require the installation of new structures, such as overhead gantries and sign bridges. It is important that any new structures meet existing clearance minimums. Additionally, these strategies may also have an impact on vertical clearance with existing devices such as sign bridges. If an agency cannot mitigate a clearance that does not meet standards, then it needs to request a design exception. Furthermore, this clearance issue may impact those vehicles allowed to use the shoulder as a travel lane. High-profile vehicles may be prohibited from using the lane if necessary. Advanced warning of the low clearance may also be an option.

Drainage Treatment

If a facility is to be modified or retrofitted as part of an ATM deployment, drainage might present a challenge if vehicles will travel on any part of the facility that was originally designed for drainage or runoff storage during rain events. Typical approaches to mitigation might include (a) moving inlets to the shoulder that will not be used for travel, (b) retrofitting inlets to allow unimpeded crossing, and/or (c) reinforcing existing or installing new inlets. The costs and operational impacts associated with the various approaches need to be evaluated and put within the context of the overall facility to determine the best solution to the drainage inlet challenge.

Rumble Strips

As with drainage treatments, any existing rumble strips on shoulders may present a challenge with strategies that may incorporate travel on the shoulders. A typical mitigation approach is to either move or removed existing rumble strips so that they would not be in the wheel path of the driving surface. Another approach is to move the rumble strip to the middle of the shoulder so that vehicles straddle the strip. This allows vehicles to use the shoulder without having the negative noise and vibration effects of rumble strips. Allowing for rumble strips does provide agencies with their original benefits without adversely affecting the operation of an ATM strategy that involves use of the shoulder.

Design Exception Process

In most instances, agencies can implement an ATM strategy on an existing facility with no significant impacts on the overall design of the facility. However, some ATM strategies may require changes to the roadway in order to accommodate the strategy, and the design of the facility may not meet the minimum design criteria required for facilities that are part of the National Highway System. Thus, the implementing agency will need to request a design exception from FHWA. Until such time that FHWA develops specific guidance for these cases, agencies should request design exceptions for any ATM project that may violate traditional design standards and policies for roadway facilities.⁽²⁴⁾

Typically, agencies submit design exception requests to the FHWA division office in their State. As part of that request, the agency must explain why it is not feasible to meet the design criteria. Additionally, the agency should identify the impacts of the substandard features associated with the design exception and how the agency plans to mitigate those standards. For example, mitigation factors for substandard geometry associated with DShL may include:

• Reduced speeds when the shoulder is in use.
• Annual average daily traffic in ranges where Highway Safety Manual analysis predicts a reduction in crashes with narrowing of the shoulder and addition of a lane.
• Use on commuter facilities during commuting periods with a high percentage of familiar drivers.
• Trucks prohibited from the shoulder.
• Extensive monitoring of the facility with ITS and/or patrol vehicles.
• Emergency refuge areas.
• DLU signage allowing closure of the shoulder if it is blocked by a disabled vehicle.⁽²⁴⁾

Agencies should review the specific requirements of design exception requests for their State and factor that review process into the overall review and approval of plans for the project.

Guidance related to design standards and design exceptions on the NHS is available online (https://www.fhwa.dot.gov/design/standards/qa.cfm). Information on mitigation strategies for design exceptions is also available online at FHWA's website (https://safety.fhwa.dot.gov/geometric/pubs/mitigationstrategies/index.htm).

Traffic Control Design

For ATM to be effective, motorists must understand what application is operational so that they behave accordingly. For example, with DShL, motorists need to know whether they are allowed in the shoulder, the proper placement of their vehicle laterally within the shoulder, and whether the use of the shoulder lane is in a state of flux. Agencies rely on various types of traffic control devices to communicate dynamic operations to motorists. Additionally, drivers need to understand lane control signs (LCSs) and dynamic message signs (DMSs) that might be used in ATM applications as well as the signage associated with DSpL.

Currently, the Manual on Uniform Traffic Control Devices (MUTCD) contains language regarding the use of LCSs and DMSs. However, most of the lane control signal language targets reversible lane applications, not congestion or lane closures on freeways or shoulder use. Thus, agencies implementing DShL as part of their ATM program have used engineering judgment to design, implement, and operate the signage used for DShL. This process has led to the implementation of several symbols that are not currently included in the MUTCD, and also the use of supplemental text on LCSs (e.g., MERGE, CLOSED, and 1 MILE) to help explain their intended meaning. Furthermore, the MUTCD provides no guidance with respect to supplemental pavement markings and static signing that also might convey shoulder use information to travelers. In the absence of this guidance, agencies have often installed a solid stripe on the outside edge of the shoulder and installed static regulatory or warning signs indicating when shoulder use is available.

Agencies that would like to experiment with new traffic control devices for ATM strategies that are not currently addressed in the MUTCD should review the process for obtaining experimentation approval for new devices (https://mutcd.fhwa.dot.gov/experflow.htm).

With respect to the use of LCSs within the freeway environment, previous research has shown that the steady downward green arrow is essentially understood by all motorists. Although not quite as uniformly comprehended, the steady red X also seems to have a strong inherent meaning to motorists. Overall, there continues to be a need for symbols that clearly and distinctly convey (a) when a lane is closed ahead and the direction in which the motorist needs to vacate the lane, and (b) when a lane is open but motorists should use extra caution (see references 53, 54, 55, 56, and 57).

Additional research related to LCSs and variable speed limit signing showed that participants frequently interpreted the ATM signs correctly as the signs were presented in sequence for a given scenario. Some errors included interpreting advisory DSpL signs as regulatory speed limit signs, incorrectly interpreting green overhead guide signs, misinterpreting the lane closed ahead sign with a legend, and confusing the meaning of the lane open with caution options (both static and flashing).⁽⁵⁸⁾

With respect to QW, the latest edition of the MUTCD provides guidance on the use of static warning signs to alert drivers to stopped traffic in advance of roadway segments that regularly experience traffic congestion as a function of posted or 85^th-percentile speed, traffic conditions, and sign legibility distance.⁽⁵⁹⁾ Current guidelines range from 100 ft to 1,350 ft, depending on the speed and conditions. However, it is important to note that the possible dynamic application of these signs is not specifically addressed in the guidance. Guidance related to the use of permanent changeable message signs (CMS) is also provided in the MUTCD⁽⁶⁰⁾, which may address some dynamic operations as long as messages meet the standards and guidance of good message design included in this section.

Additional Traffic Control Devices

Additional signs and pavement markings are frequently used by agencies to supplement information related to ATM strategies. Typical messages that may be displayed on DMSs in conjunction with various strategies, such as with DShL, DJC, DLUC, or QW, might include messages indicating specific operational or weather conditions or providing guidance information to travelers. With respect to DMS messages, as long as the message meets the standards and guidance of good message design, it is appropriate for use in the United States. An example of a signing used as part of DShL in Seattle is shown in Figure 21.

Figure 21. Photo. DShL signing, Seattle, Washington (Source: WSDOT).

MUTCD Experimental Approval Process

Many of the ATM signs and procedures for such applications as DLUC and variable speed limits, as used in Europe and in the initial ATM implementations in the United States, are not currently described in the MUTCD.⁽⁶¹⁾ A request to FHWA for experimental approval is necessary for any messaging or signage that is not compliant with or included in the MUTCD.¹ As such, a request to experiment should be factored into the overall design and development process and timeline to ensure approval is received prior to implementation. Early coordination with FHWA is recommended on MUTCD issues.

ITS Design

The backbone of a successful ATM application is technology. Having the ability to know in real time what is happening on the facility and being able to dynamically and proactively deploy any ATM strategy is essential. To that end, ITS and other technological applications are part of a robust and flexible system that is available to facilitate the dynamic aspect of ATM. The following sections highlight specific technology needs for ATM.

Hardware

A considerable amount of field hardware may be necessary for ATM deployment. This hardware includes equipment to effectively communicate to travelers that an ATM strategy is in operation as well as hardware that helps provide information to system operators in real time. This equipment may include^(3,(62)):

• Overhead sign gantries or shoulder-mounted sign structures spaced appropriately.
• Lane control signals installed on gantries or shoulders that indicate lane use or shoulder availability.
• DSpL sign provisions or consideration with the design of LCSs.
• DMSs to convey ATM-related information, including queues, speed limits, and shoulder use.
• Closed circuit televisions (CCTVs) along the corridor to allow operators to check for obstacles (disabled vehicles, debris, etc.) or incidents before opening or closing lanes or the shoulder to traffic and to monitor operations.
• Roadway sensors to facilitate advanced incident detection.
• Roadway sensors to gather traffic-related data.
• Automatic vehicle detection in any emergency refuge areas.

Overhead guide signs can facilitate the operation of ATM strategies by adapting to the current width of the roadway. In other words, when specific lanes are open to traffic, guide signs could provide information to direct travelers to open lanes, including the shoulder lane as if it were a permanent travel lane. This can be accomplished with either DMSs or rotational prism signs that are blank when the ATM strategy is not operational.

Connectivity

All of the hardware installed on the facility may have direct connectivity with the regional transportation management center (TMC) that is responsible for operating and monitoring the ATM deployment. The connectivity should be capable of providing field-related information in real time so that the most recent information about operational performance is available to system operators. The method of establishing this connectivity varies depending on the field hardware deployed and the preexisting connectivity in the corridor.

Data

At a minimum, the following data—all of which can be provided by in-field hardware—are necessary for successful implementation of an ATM system because they provide critical information to the system operators regarding facility conditions that might warrant deployment of a specific strategy:

• Traffic volumes.
• Travel speeds.
• Occupancies.
• Incident presence and location.
• Shoulder availability.

Software Design and Integration

Along with both the civil and technology aspects of the ATM system (ATMS), careful consideration of the software that operates the system should be reviewed and determined. This section highlights considerations needed to determine whether current software is sufficient or if new software is warranted to operate the ATMS.

The objective of the proposed ATMS is to gain the capability to dynamically adjust traffic operations along the corridor in real time based on scheduled/reoccurring or unscheduled events. An example is opening the shoulder for vehicle use during recurring peak-period congestion or in response to nonrecurring weather, traffic, crash, or special event conditions. The system operators will utilize a robust ATM software solution that will monitor conditions along the corridor and alert them when deviations from the expected standard conditions occur.

The operators then will be able to respond to the deviations based on recommendations from the software. They will utilize the software to provide information or instructions for motorists, such as lane closures or speed reductions. The ATM software recommendations need to be quick, precise, and fluid so that operators can respond in a timely manner. ATM software should incorporate a relatively high level of automation based on the granularity of the information at the lane and ramp level, the volume of data relative to the density of the time intervals that the data are collected, and the amount of information to be communicated to the road user.

When designing the software for an ATM system, agencies need to consider any current software operating in the TMC, whether the new software will be developed in house or via external contract, as well as specific design considerations impacting deployment such as cost, testing, expansion, integration, and maintenance.

Current Software

Several States currently have existing ATMS software that is used to operate ITS devices outside an ATMS. If an agency currently uses an ATMS software solution, it should be assessed to determine the capabilities relative to operating the new ATMS. If the existing software cannot support the ATM strategies identified, the magnitude of required software modifications should be evaluated.

Typically, ATMS software developed solely for freeway or arterial operations does not offer modules or algorithms dedicated to managing components of an ATMS. Currently, the footprint of ATM deployments in operation within North America is relatively limited. Moreover, two of the pioneer North American deployments (WSDOT and Minnesota Department of Transportation [MnDOT]) utilize software that was developed in-house. An example of the ATM software used in Seattle is illustrated in Figure 22.

Figure 22. Illustration. WSDOT ATM software, Seattle, Washington (Source: WSDOT).

If an agency is looking to utilize its existing ATMS software, the current software's capability and functionality must be assessed against the software requirements defined for the ATM implementation to assess the level of effort required. The software requirements will be derived from the ConOps and other system engineering documents developed during the project planning phase. In addition, the software requirements will align with any standard operating procedures (SOPs) developed for the ATM deployment and any existing ATMS software platform(s) with which the ATM software must be integrated.

The current vendor should be involved in refining the software requirements in order to promote effective software modifications of the existing software. Additionally, the current vendor should be involved with stakeholder meetings to facilitate a better understanding of the identified changes needed within the software and to support better coordination of the modifications.

New Software with Existing Software

States that are considering a new solution for the ATM system while they currently have ATMS software should be very mindful of the advantages and disadvantages of having two systems operating devices at the same facility and/or even operating the same devices.

If the devices are located in an area that may not always operate as an ATM, then the software requirements should include operational changes for primary control and message types on the signs. The priority level or response plans may change or deviate a bit from statewide initiatives since one software solution will need to be the primary control. If this is not agreed upon, there could be conflicts between operators and software during ATM operations. This situation runs the risk of decreasing drivers' perceptions and resulting in an unreliable system.

Design Considerations

There are several factors to consider when designing or detailing software requirements:

• Cost of the modifications—Is the cost within budget?
• Implementation time—Will the software development be completed prior to the construction of the design?
• Changes to operation standard operating procedures (SOPs)—Do the SOPs need to be updated to reflect software changes or ATM changes?
• Impacts for operators—Are the changes to the user interface intuitive?
• System impacts—Is the system mainly automated or semi-automated?
• Compatibility with information technology (IT) —Are the changes or new software compatible with the current IT network, security, and so forth?
• Agency source ownership—Does the agency want to own the source code?
• Available support—Will the vendor or State personnel be able to support the software?
• Software interactions—Is the software capable of interacting with other software (i.e., vendor software)?
• Expansion—Is the software capable of expanding if additional ATM strategies are needed?
• Testing—Although testing activities will take place during the implementation stage, can a structured software-testing framework be developed that aligns with the central component and roadside component's schedule and testing?
• Maintenance—Similar to any technology implementation, effective maintenance is key to the consistent operation of the ATM corridor. Can maintenance be achieved through either a commitment from an agency's information technology department or a maintenance contract with the selected software vendor?
• Configuration management—As field equipment is upgraded or updated, it is important for the agency to apply configuration management principles to all elements of the system. Will changes in configuration affect the utility of the software, and can they be managed to avoid impacts to the performance of the overall system?

An example of the control interface that WSDOT uses to consider implementation alternatives is illustrated in Figure 23.

3.4 PERFORMANCE-BASED PRACTICAL DESIGN

Performance-based practical design is an approach to decision making that helps transportation agencies better manage their infrastructure investments. The process helps ensure that agencies meet their system-level needs and performance priorities within the context of limited resources.⁽⁶³⁾ Related to context-sensitive solutions, PBPD allows agencies to use a variety of operational and safety analysis tools to evaluate and compare the performance of various alternatives or projects.

ATM projects are a logical fit for PBPD. As discussed previously, agencies conduct thorough analysis and simulation to assess ATM strategies for their jurisdictions. Simulation and modeling exercises help them evaluate various ATM strategies throughout the development process, from the planning stage to the operations. This approach focuses on performance improvements that benefit both the project and the overall system. Furthermore, PBPD allows an agency to analyze each element of a project in terms of value, need, and urgency to help maximize the return on the investment, which is the overall objective of ATM strategies as they relate to the goals of TSMO.

One click places the red X just downstream of the incident. This will populate 3 gantries full of LCSs and shoulder-mounted signs (SMSs) associated with the incident location. Operator reviews, overrides if needed, then accepts and deploys. Scenario 1: Two center lanes blocked. 2 red X's are placed just downstream of the blockage. SMS reads "2 CTR lanes blocked." Upstream gantry has yellow merge arrow LCS directing approaching traffic to the adjacent lanes. The remaining LCSs are displaying green arrow indicating the open lanes. Scenario 2: Similar to scenario 1 with only one center lane blocked. The upstream gantry has double merge arrows pointing to the 2 adjacent lanes. Scenario 3: When HOV lane is blocked, HOV traffic can merge to any available GP lane. When the GP lane adjacent to the HOV lane is blocked, traffic in this GP lane can only be directed into the adjacent GP lane, not into the adjacent HOV lane, unless the operator overrides and opens the HOV to all.

Figure 23. Illustration. WSDOT ATM control interface and preview panel (Source: WSDOT).

3.5 TECHNOLOGY, PROCUREMENT, AND TESTING

ATM projects require a significant amount of technology along with software and software integration. As such, the implementation of an ATM system follows that of a traditional ITS project, which requires an integrated ATMS platform to recognize the full benefits of an ITS deployment. Delays in the software development and deployment can be mitigated by operating the ITS subsystems using the ITS subsystem vendor software (e.g., vendor-provided DMS software). For an ATM implementation, the overall system relies on integrating subsystems to gain benefits of the overall solution. The integrated software must be operational and ideally have all interfaces with new or legacy platforms in place prior to activating the ATM system.

Software Delivery Models

The procurement and deployment of software can be achieved through a diverse range of delivery methods. At this point in the North American market, there are a limited number of ATM software packages in place and fully operational.⁽⁶⁴⁾ For both WSDOT and MnDOT deployments, the agencies chose in-house resources to develop their ATM software. This approach built upon the existing ITS platforms and provided an effective approach for expanding existing infrastructure to support the ATM system. In the case of VDOT, the department requested that its current ITS software vendor modify the existing commercial ATMS offering to incorporate the ATM functionality. In the case of Ohio Department of Transportation (ODOT), the agency acquired the services of a software developer to enhance its existing ATMS software.

ATM software can be procured in-house or via contract commercial development. Two strategies for the overall development can be the development of the software as an extension or module of an existing operational platform or as a standalone platform. It is important that the software align with the ATM ConOps and interface with any legacy platforms that might be used for ATM operations.

As shown with the sampling of existing implementations, agencies have yet to demonstrate a true trend in the development and deployment of ATM software. While software procurement choice is a design decision, incorporating the software development, training, and acceptance during implementation is critical to the successful operations of the ATM on day one. Regardless of the software procurement choice (in-house development as an extension or module of the existing platform; in-house development as a standalone platform; commercial development as an extension or module of the existing platform; or commercial development as a standalone platform), it is critical to address the following items during implementation:

• Confirm all software requirements with the selected solution provider as soon as practical.
• Confirm that all software requirements align with the identified standards and components that will be utilized as part of the ATM project.
• Confirm requirements necessary for interfacing with legacy platforms as identified for effective ATM implementation.
• Confirm that software requirements align with the ATM ConOps so the system will deliver the stakeholder's vision.
• Refine ATM SOPs during the requirement development and software implementation.
• Develop a training plan and user manual to support the implementation of the software.
• Develop a comprehensive laboratory environment that consists of actual devices in concert with simulated devices in order to simulate and test the operational, safety, and failure modes of the ATM system.

Software Development Resources

Software development for an ATM system can be overwhelming for an agency even if ATMS software is in place. Since ITS projects are required to follow the systems engineering process, applying these tools to the software component facilitates a more efficient implementation. The primary goal for the software development is to ensure from day one that the built system achieves all of the defined requirements and performs how the agency had envisioned. The following available systems engineering resources provide an agency with key activities, testing recommendations, and recommended development practices to manage the progression of the software within the defined budget and schedule.

• FHWA Systems Engineering Guide—Section 4.6.
• Institute of Electrical and Electronics Engineers—Standard 29148-2011 Systems and Software Engineering.
• Caltrans Systems Engineering Guide (https://www.fhwa.dot.gov/cadiv/segb/).

ATM Application: MnDOT developed an infrastructure-based queue warning system along westbound I-94 and southbound I-35W in Minneapolis. The objective of the system was to detect traffic conditions in which crashes might occur and to deliver warning messages to drivers to increase their awareness of these conditions, potentially reducing the crash frequency along the facility. The system architecture involved a three-layer design including a crash probability layer, the control algorithm, and system control. The system was designed to interface with the existing ATM systems operating in the region. Prior to full operations, the system was tested, calibrated, and validated to ensure it was operating properly. As part of this validation, an alarm efficiency score (AES) was developed as a metric to better fit the real-time driver warning system and to ensure that the system was not overly conservative in its operation. Development of a Queue Warning System Utilizing ATM Infrastructure System Development and Field Testing, Report MN/RC 2017-20, Minnesota Department of Transportation, 2017, http://dot.state.mn.us/research/reports/2017/201720.pdf.

Traceability, Requirements, and Testing

As discussed previously, the systems engineering Vee diagram presents a traceability process to verify that the developed system meets the defined requirements. This approach provides a step-by-step process for system, subsystem, and unit-level requirement development. Each step further refines the previous to ultimately create the detailed design requirements that are used for development of both the PS&E package and software. These steps are represented on the left side of the Vee diagram.

Each step along the first half of the Vee should include either a test plan (for the detailed requirements), a verification plan (for the system and high-level requirements), or a validation plan (for the user needs). During the implementation of the system, each plan should be applied as the project team moves up the right side of the diagram. Each testing and verification step should only occur once the previous step has been completed and accepted. The final validation step maps back to the initially identified user needs (as per the ConOps). This final test is intended to confirm that the system was built acceptably, the system works appropriately, and the software was developed accurately. The WSDOT ATM testing facility used to test equipment prior to installation is shown in Figure 24, while the ATM signs undergoing testing are shown in Figure 25.

Figure 24. Photo. WSDOT ATM testing facility (Source: WSDOT).

Figure 25. Photo. WSDOT ATM sign testing (Source: WSDOT).

Material Procurement

Contrary to typical civil projects or isolated ITS projects, ATM projects can involve a complex combination of materials necessary for implementation.⁽⁶⁵⁾ In addition, they can require larger than typical quantities of certain elements, such as small DMSs or structural steel. For certain technology field components, such as over-lane dynamic message signs or variable speed limit signs, time to acquire the components should be viewed as critical path items. Likewise, acquiring certain components and protocols to support software development, testing, and training is critical and should be programmed in advance of the field element quantities. Components that must be tested with legacy platforms or platforms being developed by others outside of the ATM also should be ordered in advance to provide a structured testing process.

In support of effective project delivery, lead time and sequencing are critical concerns for overhead sign mounting structures. Given that many construction methods for these types of units may require a complete road closure, it is important that the structures be made available as defined by the project schedule. Also, it is important that a strong inspection regime be in place to confirm the specifications necessary for an ATM structure. While overhead sign structures are relatively standard roadway components, gantries for an ATM environment may have cable access points, internal cable raceways, or special mounting bracket accommodations that differ from standard structures.

The inspection regime for an ATM project is similar to that of any other ITS project. The inspection regime should be continuous throughout the project and comprise factory and pre installation/construction-level, subcomponent-level, component-level, subsystem-level, and system-level inspection and testing. This applies to both technology items such as signs and communications as well as nontechnology items such as conduits and foundations. A strong inspection regime requires that thorough documentation be submitted and approved throughout the project as opposed to a single submittal at the end. A strong inspection regime includes a rigorous evaluation of the built and under-construction project elements compared to the project specifications and requirements. In addition, the inspection regime maintains a level of distance between the construction/implementing team and the inspection team. These entities can be members of the same company, but the inspection regime should be an integrated component of the overall quality assurance/quality control (QA/QC) process that provides a fresh set of eyes on the works.

ATM Application: The following list is an overview of some key lessons learned by agencies with respect to implementation of an ATM solution: ATM systems require more precision and skill to implement than conventional traffic management systems do. As a result, enhanced education on ATM technologies and operational needs, particularly within the managing agency, increases the potential for a project's success. The procurement of durable, high-quality signs can be a critical element in the implementation of a successful ATM network. An ATM system should always supplement traffic management rather than be used as the primary method of improvement for a corridor. Continuous communication between the project managers and the software developers while the software is being tested will result in a more functional and effective overall system. Establishing a requirement traceability matrix at the onset of the project helps keep the team focused, expedites reviews, and minimizes conflicts and the need for extended issue resolution. It is recommended to advance the design beyond 30 percent during the development of design-build procurement documents. Advancing the design further will enable an agency to facilitate advance construction and procurement of material, both of which have a long lead time.

¹ Described in more detail on the FHWA MUTCD website: https://mutcd.fhwa.dot.gov/condexper.htm. [Return to Note 1]

You may need the Adobe® Reader® to view the PDFs on this page.