View source for 905.3 Transportation Impact Analysis

[[image:905.3 TIA.jpg|right|450px]]
=905.3.1 Introduction=
A Transportation Impact Analysis (TIA) evaluates the potential adverse effects of proposed projects on surrounding and supporting transportation infrastructure and services. A TIA determines if the adverse effects constitute significant impacts, and, if so, how the significant impacts can be mitigated.  The guidance in this article was developed to provide a technical approach to TIAs that is consistent, instills confidence in its findings, and sets MoDOT up for success in managing Missouri’s transportation system safely and reliably.

==905.3.1.1 Background==
Transportation Impact Analysis (TIA) is one of the critical activities for a project and can influence the project schedule, scope, and budget, as well as NEPA and AJR approvals. TIAs can impact the effort associated with all planning efforts including traffic data collection, forecasting, and analysis. Each transportation project is unique and the approach for individual projects should be modified to fit each unique project. As such, when developing the TIA, there must always be a balance between the project’s goals and objectives, available schedule and budget, and the complexity of the analysis to be performed, particularly analysis involving microsimulation or the [https://safety.fhwa.dot.gov/rsdp/hsm.aspx ''Highway Safety Manual''] (HSM).

==905.3.1.2 Purpose==
MoDOT recognizes the critical role that TIAs have on their ability to program and implement projects that provide great value to their customers. The purpose of EPG 905.3 Transportation Impact Analysis  is to ensure that TIAs developed for MoDOT are consistent with the traffic engineering and transportation planning standards of practice and include the latest research and industry best practices. EPG 905.3 Transportation Impact Analysis provides direction to project managers, project engineers and planners, consultants, and all TIA users on how TIAs should best be incorporated into a transportation project’s development.
{|style="padding: 0.3em; margin-left:10px; border:2px solid #a9a9a9; text-align:center; font-size: 95%; background:#f5f5f5" width="360px" align="right" 
|-
|colspan="2"|<center>'''Additional Information'''</center>
|-
|[[media:EPG 905.3 Transportation Impact Analysis, Technical References.docx|Technical References]]
|-
|[[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to Volume Development.docx|Accompaniment to Volume Development]]
|-
|[[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to HCS.docx|Accompaniment to HCS]]
|-
|[[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to SynchroSimTraffic.docx|Accompaniment to Synchro/SimTraffic]]
|-
|[[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to VISSIM.docx|Accompaniment to VISSIM]]
|}

=905.3.2 Methodology and Scoping=
During the development of a TIA, it is important to assess current and future safety and traffic operation conditions and the effectiveness of potential solutions using traffic and safety analysis methodologies and tools. There are several analysis methodologies and tools available for use that all vary in their scope, capabilities, methodology, input requirements, and output. The goals of EPG 905.3.2 Methodology and Scoping are to assist traffic engineers, planners, and project managers in the selection of the appropriate analysis tools and to enable effective communication of the analysis methodology and workplan through appropriate scoping documentation. The MoDOT [[media:905.3.2.5 TIA Methods and Assumptions Report.docx|TIA Methods and Assumptions Report]] is the deliverable by which MoDOT stakeholders can accomplish the goals of EPG 905.3.2 Methodology and Scoping. More information about this report template is in [[#905.3.2.5 Scope the Project|EPG 905.3.2.5 Scope the Project]].

The steps for selecting appropriate traffic and safety analysis methodologies, tools, and scoping workplans include the following:
:1.	Understand available [[#905.3.2.1 Overview of Traffic and Safety Analysis Tools|traffic and safety analysis tools]]
:2.	[[#905.3.2.2 Identify the Project’s Analytical Phase and Appropriateness of TIA|Identify the project’s analytical phase]]
:3.	[[#905.3.2.3 Determine the Project’s Analytical Context|Determine the project’s analytical context]]
:4.	Select appropriate [[#905.3.2.4 Analysis Tool Selection|Analysis Tool(s)]]
:5.	[[#905.3.2.5 Scope the Project|Scope the analysis methodology and workplan through the completion of the MoDOT TIA Methods and Assumptions Report template]].

==905.3.2.1 Overview of Traffic and Safety Analysis Tools==

===905.3.2.1.1 Traffic Analysis Tools===
Traffic analysis tools are some of the most efficient methods to evaluate transportation improvement projects. EPG 905.3.2.1 addresses quantifiable traffic operations analysis tool categories, but does not include real-time or predictive models. Traffic analysis tools include software packages, methodologies, and procedures, and are defined as tools typically used for the following tasks:
:•	Evaluating, simulating, or optimizing the operations of transportation facilities and systems.
:•	Modeling existing operations and predicting probable outcomes for proposed design alternatives.
:•	Evaluating various analytical contexts, including planning, design, and operations/construction projects.

Traffic analysis tools can be categorized into the general categories of sketch planning, travel demand models, analytical/deterministic models, and microscopic simulation models. Table 905.3.2.1.1 provides a description of these categories, in addition to pros and cons of each model type and examples of the analysis tool types. Note that travel demand models are used primarily in long-range planning completed before capacity analysis and are not covered in detail in EPG 905.3 Transportation Impact Analysis. However, the utilization of travel demand models in traffic forecasts is covered in [[#905.3.4.6 Traffic Forecast Types and Tools|EPG 905.3.4.6 Traffic Forecast Types and Tools]] and [[#905.3.4.7 Forecast Application|EPG 905.3.4.7 Forecast Application]]. 
<center>
====Table 905.3.2.1.1, Traffic Analysis Tool Categories====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE"|Analysis Tool Category!! style="background:#BEBEBE"|Description!! style="background:#BEBEBE"|Pros!! style="background:#BEBEBE" |Cons!!style="background:#BEBEBE"|Examples of Tools
|-
|Sketch Planning||align="left"|Produces general order-of-magnitude estimates of travel demand and traffic operations in response to transportation improvements.||align="left"|	• Simple & low cost<br/>•	Data needs low (just highly aggregated data)||align="left"|•	Limited in scope<br/>•	Restricted presentation capabilities<br/>•	Limited analytical robustness||align="left"|	•	HCS<br/>•	CAPX<sup>'''1'''</sup>
|-
|Travel Demand Models<sup>'''2'''</sup>||align="left"|Mathematical models that forecast future travel demand based on current conditions and future projections of household and employment characteristics.||align="left"|•	Good for use in forecasting regional population, employment, and traffic growth<br/>•	Consideration of destination choice, mode choice, time-of-day travel choice, and route choice||align="left"|•	Poor representation of operational characteristics of traffic<br/>•	Large models have lengthy model run durations and large storage needs.||align="left"|•	TransCAD<br/>•	VISUM<br/>•	Cube<br/>•	Emme
|-
|Analytical/Deterministic||align="left"|	Uses static formulas to determine the relationships of flow, speed, and density of the traffic stream.||align="left"|• Quickly predict capacity, density, speed, delay, and queuing<br/>•	Good for analyzing isolated or small-scale transportation facilities||align="left"|•	Limited in their abilities to analyze network or system effects on traffic flow<br/>•	Does not model the variability in driver/vehicle characteristics.||align="left"|• HCS<br/>•	Synchro<br/>•	SIDRA
|-
|Microscopic Simulation Model||align="left"|Simulates the movement of individual vehicles based on vehicle and driver behavior theories.||align="left"|•	Good for analyzing large-scale transportation facilities<br/>•	Interactions with other vehicles and adjacent intersections help determine MOEs||align="left"|• Requires a great amount of time and effort to build and calibrate<br/>•	Can require large computer processing time and storage requirements||align="left"|•	SimTraffic<br/>•	VISSIM
|-
|colspan="5" align="left"|<sup>'''1'''</sup> More information about [https://www.fhwa.dot.gov/software/research/operations/cap-x/ CAPX] is available.<br/><sup>'''2'''</sup> Travel Demand Models are used primarily in long-range planning completed before capacity analysis and are not covered in detail in EPG 905.3. [[#905.3.4.6 Traffic Forecast Types and Tools|EPG 905.3.4.6 Traffic Forecast Types and Tools]] includes travel demand models and other common forecasting traffic forecasting tools. [https://www.fhwa.dot.gov/planning/tmip/publications/other_reports/snapshot_travel_modeling/ch01.cfm Additional information on travel demand models] is available. 
|}
</center>
The common analysis software tools are summarized below:

:•	'''Highway Capacity Software (HCS):'''  HCS is a deterministic software that is based off the equation-based methodologies of the ''[http://www.trb.org/Main/Blurbs/175169.aspx Highway Capacity Manual]'' (HCM). HCS can be used quickly and easily with simplistic parameters and inputs. Since HCS is strictly equation-based, it does not have the ability to analyze oversaturated conditions where queues dynamically interact between closely spaced network elements, such as ramps and intersections.
:•	'''SIDRA Intersection Software:'''  The ''Signalized and Unsignalized Intersection Design and Research Aid'' (SIDRA) software is a deterministic tool that can be used to analyze roundabout operations, signalized and unsignalized intersections, single-point urban interchanges, and signalized midblock crossings for pedestrians. In the United States, SIDRA is primarily used to analyze roundabout operations because of its ability to model the effects of gap-acceptance (including roundabout geometry) on roundabout Level of Service (LOS).
:•	'''Synchro Software:'''  Trafficware’s Synchro is a macroscopic analysis and optimization software application that supports HCM methodologies and the Intersection Capacity Utilization method for determining intersection capacity. Synchro is ideally used to analyze arterials and networks of multiple signalized and/or stop/yield-controlled intersections. The Synchro software application allows users to code roadway networks in a map-based interface (with aerial imagery overlays if desired) in addition to specifying key parameters in roadway link and intersection node tables.  Then the user can specify the types of measures of effectiveness (MOEs) to quantify in auto generated summary reports. Note that Synchro is a companion model to SimTraffic (SimTraffic analysis for a project is first accessed in the Synchro interface). 
:•	'''SimTraffic Software:'''  SimTraffic is a microsimulation tool that simulates the movement of individual vehicles based on vehicle and driver behavior theories. SimTraffic is a companion model to Synchro that simulates the coded transportation network (network is coded in Synchro) and measures the performance of each individual vehicle as they move through the system. Since each individual vehicle will react differently to the influences of other vehicles, pedestrians, bicyclists, roadway geometry, and grades, models with the same geometric and volume inputs will generate slightly different results, similar to how an intersection in the field will perform differently day-to day under otherwise identical conditions. Note that SimTraffic models generally have greater data requirements than Synchro models.
:•	'''VISSIM Software:'''  VISSIM (translated “Verkehr In Staedten SIMulation” in German) software is a microsimulation tool that is used to analyze multimodal traffic flows. VISSIM is capable of analyzing signal prioritization and optimization, dynamic traffic assignments, freeway operations, traffic management strategies, pedestrian flows, and the interaction of different transportation modes. Traffic flows are simulated by moving the driver-vehicle units and by using a car-following and lane-changing logic that allows drivers from multiple lanes to react to each other. 

:VISSIM’s extensive analysis, microsimulation, and animation capabilities make it one of the most labor-intensive analysis tools available. The tool is especially effective at analyzing complex and unique geometrics and traffic patterns. It can be used to evaluate arterials and freeways, but it should not be used to analyze two-way-left-turn (TWLTL) lanes.

===905.3.2.1.2 Safety Analysis Tools===
[https://safety.fhwa.dot.gov/rsdp/hsm.aspx ''Highway Safety Manual''] (HSM) provides comprehensive countermeasure selection guidance for the various crash pattern types for particular locations, including along roadway segments, at signalized and unsignalized intersections, and for bicyclist and pedestrian related issues. Within the HSM, crash modification factors (CMFs) are introduced as values used to determine the predicted reduction in crashes from implementing a chosen countermeasure(s). Quantitative safety evaluations can be performed using the following tools that utilize HSM methodology:

:•	'''[http://tms/bi/apps/crashpredict/report MoDOT Crash Prediction Tool]:'''  The MoDOT Crash Prediction Tool is internal to MoDOT staff and utilizes Transportation Management Systems (TMS) data to analyze rural two-lane highways. The tool is used for network screening and project safety analysis; it automates crash data and provides the Level of Service for Safety (LOSS) and predicted and expected crashes.
:•	'''[[#HSM Spreadsheets|HSM Spreadsheets]]:'''  The HSM spreadsheets provide high-level overviews of the predicted number of crashes within a study corridor.
:•	'''[[#ISATe|ISATe]]:'''  The ISATe is an analytical tool to examine safety performance and to predict crashes on freeways and interchanges. This tool is a version of the HSM spreadsheet and allows for the analysis of speed change lanes, as well as ramps and ramp terminals.
:•	'''[[#IHSDM|IHSDM]]:'''  The IHSDM is a suite of software analysis tools that support HSM procedures and methodologies and are used to evaluate the safety and operational effects of geometric design decisions on highway projects.

Additional resources that can be used to supplement the tools above and assist in conducting safety analyses include, but are not limited to:
:•	'''[http://modatazone.modot.org/index.php/safety MoDOT Crash Statistics Map]:'''  The MoDOT Crash Statistics Map is internal to MoDOT, but can be accessed externally with permission.  It allows users to get a visual representation of crashes and their locations across the state. It also allows users to pull historical crash data and filter that information based on various crash and roadway attributes, such as crash type or curve radius. Data can also be filtered by more specific criteria, such as crashes involving older drivers or pedestrians. Results can be exported to either Excel or PDF for use. 
:•	'''Crash Modification Factors (CMFs):'''  CMFs are values used to determine the predicted reduction in crashes from implementing a chosen countermeasure(s). Refer to [[#905.3.6.2.8 Crash Modification Factors (CMF)|EPG 905.3.6.2.8 Crash Modification Factors (CMF)]] for more information.
:•	'''Missouri’s Strategic Highway Safety Plan (SHSP):'''  Missouri’s SHSP is the state’s plan (collaboratively developed with stakeholders throughout Missouri) to reduce fatal and serious injury crashes through an assessment of current and desired performance and a comprehensive collection of data-driven strategies. Additionally, there are regional Highway Safety Plans that are tailored to individual regions in Missouri and are used to inform the SHSP.

For more detailed information about available safety analysis tools and the appropriate applications of safety analyses, refer to [[#905.3.6 Safety Analysis|EPG 905.3.6 Safety Analysis]].
 

==905.3.2.2 Identify the Project’s Analytical Phase and Appropriateness of TIA ==
After the user understands the general background of analysis and safety tools available, the first project-specific step is to identify the analytical phase of the TIA project. The analytical phase is the stage of planning/engineering and the level of analysis at which traffic capacity analysis and/or safety analysis will be completed. Listed below is an explanation of the general analytical phases:
:•	'''Generalized Planning:'''  High level analysis of transportation system elements to obtain general order-of-magnitude estimates of performance-based capacity constraints and operational control.
:•	'''Conceptual Planning:'''  Broad criteria and system performance-based analysis on geometric and physical capacity constraints and operational systems such as traffic control and land use.
:•	'''Preliminary Engineering, Design, Operational:'''  Detailed system performance-based analysis on individual user interactions, geometry, and operational elements.

The determination of whether a TIA should be completed should be determined by factors such as if there is a new development that will generate 100 or more peak hour driveway trips or if the existing traffic on an adjacent facility will increase by at least 20%. For more details on potential triggers to determine when a TIA should be completed for a development, refer to [[#Figure 905.3.4.8.1,|Figure 905.3.4.8.1]]. Refer to [[:Category:941 Permits and Access Requests|EPG 941 Permits and Access Requests]] for additional information on permits and access requests.

==905.3.2.3 Determine the Project’s Analytical Context==
[[image:905.3.2.3.jpg|1080px|thumb|center|<center>'''Fig. 905.3.2.3.1, Analytical Context of Project<br/>Source: FHWA Report Number HOP-16-072, ''Scoping and Conducting Data-Driven 21st Century Transportation System Analyses'', published January 2017</center>]]

A project’s analytical context should be determined by assessing the following attributes of a project. These attributes are summarized in Fig. 905.3.2.3.1 and listed below:
:1.	'''Geographic Scope:'''  The study area size of the project. General categories include an isolated intersection or interchange, a roadway segment, a corridor or small network, and an entire citywide or countywide region.
:2.	'''Facility Type:'''  The transportation facility type(s) that will be analyzed during the project. Examples of facility types include arterials, highways, ramps, and isolated intersections, among other facility types.
:3.	'''Travel Mode:'''  The travel mode is the means by which transportation facility users will be traveling on the facility. This includes data collection and accurate estimates to determine the proportional breakdown of all vehicle, transit, bicycle, and pedestrian usage. 
:4.	'''Management Strategy:'''  The transportation management strategies that should be analyzed.
:5.	'''Traveler Response:'''  This attribute indicates how travelers can change their route of travel, change their travel time, use a different mode of transportation, change their destination, or cancel/create a new trip. These traveler responses would be measured due to responses to different operational improvements.
:6.	'''Performance Measures:'''  The ability of the analysis tool to produce various performance measures in the areas of safety, efficiency, mobility, productivity, and the environment. Common performance measures/MOEs include but are not limited to the list below: 
{| style="margin: 1em auto 1em auto" 
|-
|•	Level of Service (LOS)||width="15"| ||	•	Queue Length
|-
|•	Speed||	|| •	Vehicle Miles Traveled (VMT)
|-
|•	Travel Time	|| ||•	Vehicle Hours Traveled (VHT)
|-
|•	Volume Desired (Demand)	|| ||•	Travel Time Reliability
|-
|•	Actual Volumes (throughput)||	||•	Crash Reductions
|-
|•	Ridership||	||•	Benefit/Cost
|-
|•	Volume-to-Capacity (v/c)||	||•	Lives Saved
|-
|•	Density	|| ||•	Serious Injuries Reduced
|-
|•	Delay	|| ||
|}
:Two items that are important to understand for assessing performance measures include:
::'''Typical MOEs by Study Type:'''  Contextualize how MOEs considered will be used for varying study types. Table 905.3.2.3.2 summarizes typical volume-based, time-based, and accessibility MOEs to be aware of based on study type.
<Center>
====Table 905.3.2.3.2, Typical MOEs by Study Type====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width="250"|Study Type!! style="background:#BEBEBE" width="300"|Traffic Volume-Based MOEs!! style="background:#BEBEBE" width="175"|Typical Time-Based MOEs!! style="background:#BEBEBE" width="175"|Accessibility MOEs
|-
|Air quality conformity analysis||	Area-wide Vehicle Miles of Travel||	Speeds	||
|-
|Asset management, including bridge and pavement needs||	Link-specific volumes|| ||
|-
|Capital Improvement Program, prioritization||	Benefit/cost,Level of Service|| ||
|-
|Congestion management process||	Corridor volumes||	Speeds||
|-
|Corridor mobility studies||	Intersection Level of Service, intersection turning movements, traffic volumes||	Segment travel times||	 Conflict point comparisons to weight access restrictions<sup>'''1'''</sup>
|-
|Demand management plans||	Number of peak-hour trips, Level of Service||	Vehicle Hours of Delay	||
|-
|Environmental impact statements||	Vehicle Miles of Travel, emissions, traffic crashes||	Vehicle Hours of Travel	||
|-
|Evacuation plans||	Hourly traffic volumes, throughput||	Travel times||
|-
|Facility design and operations||	Design hour traffic volumes|| ||
|-
|Highway feasibility studies||	Benefit/cost, screenline volumes, Level of Service||	Vehicle Hours of Travel||	Access to labor market and jobs<sup>'''2'''</sup>
|-
|Interchange justification requests||	Traffic volumes,Level of Service|| ||
|-
|Roadway (general and freight) long-range planning||	Vehicle Miles of Travel,Level of Service||	Vehicle Hours of Travel||	Access to labor market and jobs<sup>'''2'''</sup>
|-
|Traffic impact studies||	Intersection turning movements, Level of Service, delay per vehicle|| ||
|-
|colspan="4" align="left" width="900"|'''Note:''' table is based on NCHRP 765 Table 2-1.<br/><sup>'''1'''</sup> Applicable to both capacity and safety analyses<br/><sup>'''2'''</sup> Access to the labor market and jobs (as studied at the long-range planning and feasibility study planning levels) can be studied through an assessment of delay and travel time and the constraining factors of capacity and congestion to accessing employment destinations. Regional travel demand models can be used to assess these MOEs for an entire region and to do a select link analysis that identifies a proportional breakdown of how facilities are being used to access key employers. Additionally, stakeholder surveys or travel-time contours can be used to review access to labor markets.<br/>Travel-time contours have been used to illustrate the effects of congestion on access to destinations (including the labor market and jobs). Travel-time contour maps are similar to topographical maps, with lines encircling a destination that radiate outward and do not touch. The spacing between the lines corresponds to the travel times needed to traverse them for a given distance (closely spaced lines would correspond to slower speeds than widely spaced lines).
|}
</center>
::'''Typical MOEs by Analysis Tool:'''  Table 905.3.2.3.3 provides common MOEs reported for common analysis software tools. Note that the focus of Table 905.3.2.3.3 is on comparing and contrasting the traffic operations MOEs between multiple analysis tools. It is not an exhaustive list of MOEs and does not include safety MOEs. Most safety focused tools report similar MOEs. The key differences for the safety tools include the level of detail that the particular tool can drill down to.

</center>
<center>

====Table 905.3.2.3.3, Typical MOEs analyzed by Analysis Tool====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width="400"|Traffic Operations MOE!! style="background:#BEBEBE" width="100"|HCS!! style="background:#BEBEBE" width="100"|SIDRA!! style="background:#BEBEBE" width="100"|Synchro!! style="background:#BEBEBE" width="100"|SimTraffic!! style="background:#BEBEBE" width="100"|VISSIM<sup>'''1'''</sup>
|-
|Average (Mean) Queue Length (feet)|| || || ||	✔||	✔
|-
|50th Percentile (Median) Queue Length (feet)||	✔|| ||	✔|| ||	✔
|-
|95th Percentile Queue Length (feet)<sup>'''2'''</sup>	||✔	||✔	||✔	||✔	||✔
|-
|Maximum Queue Length (feet)|| || || ||	✔||	✔
|-
|Volume-to-Capacity (v/c) Ratio||✔	||✔	||✔ || ||
|-
|Density (passenger car/lane/mile)	||✔|| || || || 				
|-
|Density (vehicles/lane/mile)||	✔|| || || ||✔
|-
|Control Delay (seconds/vehicle)	||✔	||✔	||✔ || ||		
|-
|Microsimulation Delay (seconds/vehicle)|| || || ||	✔||	✔
|-
|Travel Time (seconds)	||✔ || || ||	✔||	✔
|-
|Reliability (Percentile Travel Time Indices)||✔|| || || || 					
|-
|Percent of Time Spent Following||✔|| || || || 					
|-
|Space Mean Speed (mph)	||✔	||✔	||✔	||✔	||✔
|-
|Time Mean Speed (mph)	||	||	||	||	||✔
|-
|colspan="6" align="left" width="900"|<sup>'''1'''</sup> VISSIM can be used to specify any percentile queue results from 0% to 100%.<br/><sup>'''2'''</sup> The 95th percentile queue parameter in both SimTraffic and VISSIM are computed values (not based on “observed”/simulated trips). Therefore, the maximum queue is recommended for both SimTraffic and VISSIM instead. Refer to [[#905.3.5.2.3.5 Queue Lengths in Synchro and Sim Traffic|Table 905.3.5.2.3.5 Queue Lengths in Synchro and Sim Traffic]] for more discussion. 
|}
</center>

:For general background information, definitions, and the typical usage of MOEs, refer to the [https://ops.fhwa.dot.gov/publications/fhwahop08054/index.htm FHWA Traffic Analysis Toolbox Volume VI: Definition, Interpretation, and Calculation of Traffic Analysis Tools MOEs]. 
:7.	'''Tool/Cost Effectiveness:'''  Evaluate the management and operational considerations for selecting the most appropriate tool based on financial, personnel, or skill-related resource requirements.

==905.3.2.4 Analysis Tool Selection==
Table 905.3.2.4 displays a general list of traffic analysis and safety tools to select, which are determined by a project’s level of analysis and facility type. For a more detailed method to determine an appropriate traffic analysis tool, refer to [[media:905.3.2.4 Analysis Tool.xlsx|MoDOT Analysis Tool Selection]]. Both the generalized and detailed tool analysis methods to select a tool are only guidance to help the user. Additional, project specific concerns, such as the analysis objective and project constraints should always be considered when selecting an analysis tool.
<center>
====Table 905.3.2.4, Typical Traffic and Safety Analysis Tools by Level of Analysis====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" colspan="2" width="225"|Level of Analysis!! style="background:#BEBEBE" colspan="6" width="550"|Facility Type
|-
! style="background:#BEBEBE" width="100"|Category!! style="background:#BEBEBE"|Description!! style="background:#BEBEBE"|Isolated Intersections/Interchanges!! style="background:#BEBEBE" |Interconnected Intersections/Interchanges!! style="background:#BEBEBE"|Roundabouts!! style="background:#BEBEBE"|Freeways !! style="background:#BEBEBE"|Urban/Suburban Arterials!! style="background:#BEBEBE"|Rural Two-Lane Highways and Multi-Lane Highways
|-
|Generalized Planning||align="Left"|•	High level analysis <br/>•	General order-of-magnitude estimates<br/>•	Performance-based capacity constraints and operational control||	HCS<br/>CAPX<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup>||	HCS<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup>||	HCS<br/>CAPX<br/>SIDRA<br/></font color = "red">HSM</font color = "red">|| 	HCS<br/><font color = "red">ISATe</font color = "red">||	HCS<br/>Synchro<br/><font color = "red">HSM</font color = "red"> ||HCS<br/><font color = "red">HSM <br/>MoDOT Prediction Tool</font color = "red"><sup>'''3'''</sup>
|-
|Conceptual Planning||align="left"|•	Broad criteria and system performance based analysis<br/>•	Geometric and physical capacity constraints <br/>•	Operational systems such as traffic control and land use||	HCS<br/>Synchro<br/>SimTraffic<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup><br/><font color = "red">IHSDM</font color = "red"> ||	Synchro<br/>SimTraffic<br/>VISSIM<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup><br/><font color = "red">IHSDM</font color = "red">|| SIDRA<br/>VISSIM<br/><font color = "red">IHSDM</font color = "red">||	HCS<br/>VISSIM<br/><font color = "red">ISATe<br/>IHSDM</font color = "red">||	HCS<br/>Synchro<br/>SimTraffic<br/>VISSIM<br/><font color = "red">HSM <br/>IHSDM</font color = "red">||	HCS<br/>HSM <br/><font color = "red">IHSDM<br/>MoDOT Prediction Tool</font color = "red"><sup>'''3'''</sup>
|-
|Preliminary Engineering; Design; Operational||align="left"|•	Detailed system performance-based analysis <br/>•	Individual user interactions<br/>•	Geometry<br/>•	Operational elements||	HCS<br/>Synchro<br/>SimTraffic<br/>VISSIM<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup><br/><font color = "red">IHSDM</font color = "red">||	Synchro<br/>SimTraffic<br/>VISSIM<br/><font color = "red">HSM</font color = "red"><sup>'''1'''</sup><br/><font color = "red">ISATe</font color = "red"><sup>'''2'''</sup><br/><font color = "red">IHSDM</font color = "red"> ||	SIDRA<br/>VISSIM<br/><font color = "red">IHSDM</font color = "red">||	HCS<br/>VISSIM<br/><font color = "red">ISATe<br/>IHSDM</font color = "red">||	Synchro<br/>SimTraffic<br/>VISSIM<br/><font color = "red">HSM <br/>IHSDM</font color = "red">||	HCS<br/><font color = "red">HSM <br/>IHSDM<br/>MoDOT Prediction Tool</font color = "red"><sup>'''3'''</sup>
|-
|colspan=8 align="left" width="775"|'''Note:''' <font color = "red">Red Text</font color = "red"> is for safety tools. Also, HSM is short for “HSM Spreadsheets.”<br/><sup>'''1'''</sup> HSM Spreadsheets are appropriate for intersections and ramp terminal intersections, but not interchanges.<br/><sup>'''2'''</sup> ISATe is appropriate for interchanges, but not intersections.<br/><sup>'''3'''</sup> The MoDOT Prediction Tool is appropriate for rural two-lane highways only.
|}
</center>

===905.3.2.4.1 Use of Complementary Traffic Analysis Tools===
There are certain situations where it is beneficial to use multiple analysis tools to blend together the complementary capabilities and strengths of certain tools. A few common situations of blending tools together are provided below. Note that this list is not intended to be prescriptive nor comprehensive.

'''Synchro and SimTraffic'''

MoDOT recommends that SimTraffic runs be completed for transportation projects where traffic volumes are at or near capacity or where operations in one part of the study area are expected to have a noticeable impact on other study area locations. This will allow decisionmakers to form a more complete understanding of the traffic flow patterns for a particular project. To help inform this decision, Table 905.3.2.4.1 displays a comparison of key attributes that Synchro and SimTraffic have:
<center>
====Table 905.3.2.4.1, Synchro and SimTraffic Comparison====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" |Attribute Descriptions!! style="background:#BEBEBE" |Synchro!! style="background:#BEBEBE" |SimTraffic
|-
|align="left"| High-level planning study||	✔||	✔
|-
|align="left"|Geometry and volume attributes are key inputs||	✔||	✔
|-
|align="left"|Software can optimize signal timings||	✔||	
|-
|align="left"|Interactions with other vehicles and adjacent intersections help determine MOEs|| ||	✔
|-
|align="left"|Realistic traffic simulations can be displayed	|| ||✔
|-
|align="left"|Does not require large computer processing time and storage requirements||	✔||
|-
|align="left"|A single error at one intersection will NOT impact all intersections||	✔||
|-
|align="left"|Better suited to anticipate delay when upstream bottlenecks exist||	✔||
|-
|align="left"|Better suited to show delay when queuing and blocking problems exist||		||✔
|}
</center>

'''Synchro and HCS'''

This could occur when a project encompasses an arterial, an interchange, and multiple freeway segments when microsimulation is NOT required. In this scenario:
:•	Traffic conditions would be undersaturated. Otherwise, a microsimulation tool should be used.
:•	HCS would be used to analyze freeway merging, diverging, and weaving segments
:•	Synchro would be used to analyze the signalized intersections along the arterial as well as the operations on the arterial facility.

'''Synchro or HCS and VISSIM'''

This could occur when a project encompasses an arterial, an interchange, and multiple freeway segments when microsimulation is required. In this scenario:
:•	Traffic conditions would be undersaturated, but microsimulation would still be needed.
:•	HCS would be used to analyze the operations of the freeway.
:•	Synchro would be used to analyze the signalized intersections of the arterial.
:•	Synchro could be used to develop optimized traffic signal timings for VISSIM.
:•	VISSIM would be used to analyze the intersections, arterials, interchanges, and freeway operations to simulate interactions in one model.

'''Synchro and SIDRA'''

This could occur when a project encompasses an arterial that includes a roundabout and one or more signalized or unsignalized (non-roundabout) intersections. In this scenario:
:•	Microsimulation would NOT be needed.
:•	Synchro would be used to analyze the signalized and unsignalized (non-roundabout) intersections of the arterial.
:•	SIDRA would be used to analyze the operations of the roundabout.

'''SIDRA and VISSIM'''
This could occur for the analysis of a roundabout with oversaturated traffic conditions or with impacts to adjacent intersections. In this scenario:
:•	Microsimulation would be needed.
:•	SIDRA would be used, initially, to analyze the operations of the roundabout.
:•	VISSIM would be used to analyze the roundabout (and adjacent intersections). This could include microsimulation results and animation.

==905.3.2.5 Scope the Project==
It is important for the project manager, modeler, reviewer, and other involved personnel to develop an effective plan for conducting the necessary analysis. All parties also must agree on assumptions to be made to complete the analysis.  The [[media:905.3.2.5 TIA Methods and Assumptions Report.docx|TIA Methods and Assumptions Report]] will ensure that expectations are set before any analysis is performed and it sets the stage for effective communication throughout the process.  The intent is for this report to be updated as methodologies and assumptions change during the project.  This report can then be referenced and appended to later project reports.

The intent of EPG 905.3.2.5 Scope the Project is to inform the TIA Methods and Assumptions Report template, which includes section numbers that correspond to the step numbers below. 
:1.	'''Stakeholder Acceptance:''' Identify and coordinate with the appropriate stakeholders. The ''TIA Methods & Assumptions Report'' provides a section to enter key stakeholders that include “MoDOT Representative,” “FHWA Representative,” and “County/Municipal Representative.” Additional stakeholders can be documented as needed. 
:2.	'''Understand Project Background Information.''' (“Introduction” section in ''TIA Methods & Assumptions Report''):  Identify the project’s need for study, previous studies completed, the study’s schedule, and key project stakeholders.
:3.	'''Definition of the Study Area:'''  Determine the study area based on the logical geographic termini, the project purpose and need, and the expected limits of potential impacts. It is especially important to ensure that the analysis study area is extensive enough in its geographic reach to reasonably estimate transportation and land development impacts.  This may differ for the traffic analysis and the safety analysis. The study area should be agreed upon by the project team, including FHWA when applicable, during project scoping. Below is guidance for typical study limits of different project types. 
:* '''Freeways''' – at least one interchange beyond construction limits, including that interchange’s on and off ramps closest to the construction at a minimum or an evaluation of the full adjacent interchanges if required and agreed upon by all stakeholders in the project scoping process 
:* '''Ramp terminals''' – one major intersection beyond construction limits and to the next interchange on freeway. In cases where next intersection is close (e.g., outer road), consider the functional area of the interchange. 
:* '''Arterials''' – one major intersection on either end of the project. Include minor streets at least up to next major upstream intersection or end of street, to the greatest extent possible. 1000 feet is desirable for queue evaluation, even if space may not be physically available.
:4.	'''Analysis Years/Periods: ''' Information is provided below on time of day analysis and on typical analysis years. Sometimes this step is best completed iteratively with Step 6 (traffic forecasting) to determine appropriate horizon years based on forecasting assumptions and constraints (refer to Step 6). This may differ for the traffic analysis and the safety analysis.
::a.	'''Time of Day Analysis:'''  Typically, only AADT forecasts are needed for planning level studies. Project-level operational analysis will typically include AM and PM peak period forecasts. Safety studies may perform time of day analysis at specific locations, such as schools, which see disproportionate volumes during peak hours. Determine if a peak period of one hour is sufficient, or if a longer period is needed to capture the buildup and dissipation of congestion.
::b.	'''Specify Analysis Years:'''  The appropriate years to analyze for a project vary based on how the project will be used. A 20-year horizon after the opening year of the project, at minimum, is typically used to forecast future travel demand on the network. The planning horizon could be shorter for design projects. 
:Table 905.3.2.5 provides basic information about typical analysis years studied. All of the analysis years listed should be included in the project analysis, unless otherwise justified and discussed with the appropriate MoDOT representatives. For all projects, it is important that the “Existing Base Year” be included due to its importance for model calibration to existing year traffic conditions.
<center>
====Table 905.3.2.5, Analysis Years====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" |Year!! style="background:#BEBEBE" width="400|Description
|-
|Existing Base Year||align="left"|	A base year that is typically as close as possible to the current year.
|-
|Assumed Interim/Opening Year||	align="left"|Expected future year that the project will open; in the case of phased projects this might be a sequence of intermediate analysis years.
|-
|Horizon/ Design Year||	align="left"|A future analysis year that is at least 20 years into the future after the opening year of the project.
|-
|Horizon Years for Safety Projects||align="left"|Use the life cycle length of the longest countermeasure for the horizon year. <br/>Consider setting a maximum safety horizon year of 20 years after the opening year of the project and documenting special circumstances if setting a horizon year longer than 20 years out is necessary.
|}
</center>

:5.	'''Design Alternatives:'''  Determine all appropriate design alternatives that the study will consider. This step will require collaboration with stakeholders. Sometimes this step is best completed iteratively with Step 6 (traffic forecasting) to determine appropriate alternatives based on future travel demand.  The design alternatives may not be known during the initial scoping of the project but will be determined during the study.
:6.	'''Traffic Forecast:'''  A traffic forecast should be completed to understand current and future travel demand on study area facilities. This involves determining the appropriate forecast scenarios and assessing the characteristics that are influencing travel demand.
::a.	'''Determine Appropriate Forecast Scenarios:'''
::::i.	Determine if additional transportation projects (other than the subject project) should be included in the forecast. A common situation includes projects that are assumed to be completed in a forecast Future Year as the result of a Metropolitan Planning Organization’s (MPO’s) Metropolitan Transportation Plan (usually fiscally constrained or committed, but not illustrative projects).
::::ii.	Verify if multiple changes to land use characteristics and/or socioeconomic data (e.g., households, population, employment) should be forecasted.
::::iii.	Determine the different transportation project geometric alternatives that should be forecasted (e.g., multiple bypass scenarios that could potentially bypass a town going to either the east or west).
::b.	'''Assess Travel Demand Characteristics:'''  Complete an early assessment of the current and anticipated travel demand in the study area. Examples of items to document include:
::::i.	The nature of demand in the corridor in terms of trucks versus passenger cars, through versus local trips, or non-discretionary trips (such as commute to work) versus discretionary trips (such as shopping trips).
::::ii.	Unique major generators in the corridor.
::::iii.	What magnitude of growth in travel demand is anticipated?
::::iv.	The extent of need for the project based on today’s travel conditions versus anticipation of growth. 
:7.	'''Traffic Operations Analysis: ''' Determine and document the appropriate traffic operations analysis software program(s) and software version for use in the study. This decision should be made in coordination with stakeholders. Refer to [[#905.3.2.1 Overview of Traffic and Safety Analysis Tools|EPG 905.3.2.1 Overview of Traffic and Safety Analysis Tools]] through [[#905.3.2.4 Analysis Tool Selection|EPG 905.3.2.4 Analysis Tool Selection]] for detailed information to help inform the decision-making process for selecting a tool.
:8.	'''Safety Analysis:'''  Determine and document the appropriate safety analysis software program(s) and software version for use in the study. This decision should be made in coordination with stakeholders. Refer to [[#905.3.2.1 Overview of Traffic and Safety Analysis Tools|EPG 905.3.2.1 Overview of Traffic and Safety Analysis Tools]] through [[#905.3.2.4 Analysis Tool Selection|EPG 905.3.2.4 Analysis Tool Selection]] and [[#905.3.6 Safety Analysis|EPG 905.3.6 Safety Analysis]] for detailed information to help inform the decision-making process for selecting a tool. 
:9.	'''Conclusion: ''' Document a brief summary of the study’s intent and methodology.
:10.	'''Record of Revision:'''  If applicable, document the revision number, date of revision, and content that has been revised.

=905.3.3 Data Collection=
==905.3.3.1 Overview==
Federal Highway Administration's (FHWA) [https://www.fhwa.dot.gov/policyinformation/tmguide/tmg_fhwa_pl_17_003.pdf ''Traffic Monitoring Guide'' (2016)] describes federal guidelines for establishing and maintaining traffic monitoring programs and guidance for traffic monitoring methodologies. The guide especially focuses on maintaining a continuous data program, a short duration data program, calculations and computations to apply to raw data, and quality assurance processes.

In addition to federal guidelines, state-level departments of transportation (DOTs) usually have monitoring systems responsible for programming, collecting, analyzing and reporting traffic volume and vehicle classification data on Interstates and highways in their jurisdiction. MoDOT maintains an [https://www.modot.org/traffic-volume-maps online interactive AADT map] that is updated annually. This map breaks down traffic by both generalized vehicle classifications and directional, hourly volume breakdowns. '''Disclaimer:''' MoDOT’s interactive AADT map shows volumes at some locations that are associated with actual count data and some data that are estimated volumes (not based on count data). If the analyst has any data concerns, then please contact the MoDOT TMS unit.

For transportation projects, it is important to work with MoDOT to determine how to best analyze existing traffic count data provided by MoDOT or other local sources and if additional project-specific short duration counts will be needed to meet project needs. EPG 905.3.3 Data Collection will answer these guiding questions about traffic data collection: 

:1.	[[#905.3.3.2 Understand the Needs of the Project (The “Why”)|Why Collect Count Data]] – Understand the needs of the project
:2.	[[#905.3.3.3 Determine If or When to Best Collect Data (The “When”)|When Gather Count Data]] – Determine if or when to collect data 
:3.	[[#905.3.3.4 Assess What Type of Data is Needed (The “What”)|What Count Data to Collect]] – Assess what type of data is needed.

==905.3.3.2 Understand the Needs of the Project (The “Why”)==
To determine what traffic count data is needed, it is important to think about the background of a transportation project’s goals. The NCHRP 765 states that “analysts should be cognizant of the context in which the information they produce will be used and come to an understanding about the MOEs to be published and presented at the outset of a study.” 

Developing an understanding of the data collection needs for a project takes place during project scoping. The MOEs to be used during the study should help inform the data collection needs.  See [[#905.3.2.3 Determine the Project’s Analytical Context|EPG 905.3.2.3 Determine the Project’s Analytical Context]] for guidance about the determination of MOEs.

General questions to consider when determining data needs are:
:•	Do we need intersection turning movement count data?
:•	Will only particular peak hour data be required, or will a 24-hour estimation of a typical weekday’s travel be needed?
:•	What additional data will be necessary to address project-specific MOEs (such as queue lengths, vehicle speeds, travel time, etc.)?

==905.3.3.3 Determine If or When to Best Collect Data (The “When”)==
'''Is New Traffic Data Needed?'''

Age limits for the relevancy of traffic counts are context sensitive to the regional characteristics (urban, rural, or suburban) and recent growth patterns of an area (i.e., has there been recent developments that would influence traffic volumes?). MoDOT recommends that new traffic count data should be collected if the most recent, available data is more than three years old.

As noted in [[#905.3.3.1 Overview|EPG 905.3.3.1 Overview]], MoDOT maintains an online interactive AADT map that is updated annually and includes both generalized vehicle classifications and directional, hourly volume breakdowns. MoDOT’s official AADT data should be the first data source to refer to when determining data needs. However, always be cognizant if turning movement counts or other data breakdowns (e.g., 15-minute volume bins, vehicle speeds, etc.) will be needed in addition to existing AADT data. ([[#905.3.3.4 Assess What Type of Data is Needed (The “What”)|EPG 905.3.3.4 Assess What Type of Data is Needed (The “What”)]] elaborates on this.)

Regardless of the precise age of the pre-existing count data, it is important to determine what the unique data needs are for a transportation project. General questions to help determine if new count data is needed are:
:•	Is there pre-existing count data that has been collected within the past three years that is reflective of present-day traffic patterns for the area?
:•	Have there been recent changes to the general area’s transportation network?
:•	Have there been recent land use changes or new developments completed in the area?

Please refer to [[#905.3.3.5 Data Collection Plan and Checklist|EPG 905.3.3.5 Data Collection Plan and Checklist]] for guidance about documenting assumptions.

'''When to Collect Data'''

For most traffic studies, it is important for traffic counts to reflect normal weekday and/or peak hour traffic conditions (unless performing special studies). Certain conditions may not yield the best or most accurate data. FHWA's [https://www.fhwa.dot.gov/policyinformation/tmguide/tmg_fhwa_pl_17_003.pdf ''Traffic Monitoring Guide''] advises that traffic counts should not be collected on Fridays, for example, since they tend to have lower morning volumes and slightly higher afternoon volumes than other weekdays. The guide also states that traffic volumes on Mondays can be fairly similar to typical weekdays, but if you are to complete traffic counts on a Monday, be sensitive to the location (i.e., Monday counts in areas influenced by rural, recreational areas can experience patterns similar to a Friday). As a result, it is recommended to avoid collecting traffic count data on Mondays and Fridays altogether and only collect data from Tuesday to Thursday. Exceptions would include unique studies where special event and/or recreational trips are a concern, though even then, it is advised to provide the special event/recreational data as a supplement to typical (Tuesday – Thursday) weekday traffic data.  

Determining when not to collect data can provide more accurate information. MoDOT recommends the following traffic count rules for when NOT to collect data:
:•	Sundays, Mondays, Fridays and Saturdays
:•	When public schools are not in session (generally, late May through early August, depending on the study area; the exact timeframe should be confirmed prior to collecting traffic data)
:•	During holiday periods when travel patterns are not routine (from a week before Thanksgiving to a week after New Year) 
:•	Days when special events at major traffic generators may disrupt routine traffic patterns 
:•	During special events that generate traffic that is not typical of everyday operations 
:•	During or immediately following significant inclement weather events (e.g., blizzards, heavy rain, etc.) 
:•	During federal and/or state issued advisories or restrictions (an example would be travel advisories issued for the COV-19 pandemic)
:•	During the week following a time change due to the start or end of Daylight-Savings Time 
:•	During construction in or near the project area 
:•	During traffic incidents (e.g., crashes) that disrupt normal traffic patterns 
:•	During off-peak season when traffic is typically influenced to be lower than during a seasonal peak. For example, it may not be desirable to count roadways around the Lake of the Ozarks during winter, when demand is significantly less than during the summer.

==905.3.3.4 Assess What Type of Data is Needed (The “What”)==
The following guidelines are recommended for intersection turning movement counts, roadway segment counts, data needed for various software tools, and the determination of vehicle classifications that will be used for traffic and safety analysis. Other data may be needed for traffic and safety analysis, but the below count data has specific MoDOT requirements.  Other data collected should follow standard industry practices.

'''Intersection Turning Movement Count Recommendations '''
:•	For a transportation project that includes multiple intersections, collaborate with all appropriate parties to determine what intersections need turning movement counts. Turning movement counts are typically needed if:
:::o	The intersecting road carries at least 400 vehicles per day.
:::o	The intersection has turning movement count data older than three years. Also, ensure that the recently collected count includes all appropriate data needed for the project.
:•	Provide generalized personal vehicle and heavy truck classifications (collecting heavy trucks in MoDOT standardized categories is preferred – refer to [[#Vehicle Classifications|Vehicle Classifications]])
:•	Collect the data in 15-minute intervals
:•	If trying to estimate peak hour traffic volumes only, then collect at least two-hours in each peak period. Existing segment hourly counts can be used to inform the timing for the two-hour counts, but typically 7:00 AM to 9:00 AM and 4:00 PM to 6:00 PM will include the peak hours.
:•	Strongly consider a minimum 12-hour turning movement count from 6 AM to 6 PM if trying to estimate 24-hour traffic volumes, if the traffic peak may occur during midday, and/or if a signal warrant analysis is anticipated
:•	Collect bi-directional data for all turning movements (covers both directions).

'''Roadway Segment Count Recommendations'''
:•	For a transportation project that includes roadway segments, review existing MoDOT AADT data to determine what recent data is available. Roadway segment counts are recommended if:
:::o	It supplements the turning movement counts with project-specific roadway segment counts. These segment counts should be at strategically important locations to capture key traffic patterns and assess the influence of nearby traffic generators.
:::o	There is a gap in recent, relevant historic AADT on the roadway. Typically, it is advised to use traffic data that is no older than three years old.
:::o	The only available historic AADT on MoDOT’s Interactive AADT map are volume estimates that are not based on actual count data (confirm with the MoDOT TMS unit if there are any concerns or questions about data source).
:•	Provide generalized personal vehicle and heavy truck classifications (collecting heavy trucks in MoDOT standardized categories is preferred – refer to [[#Vehicle Classifications|Vehicle Classification]])
:•	Collect the data in one-hour intervals at a minimum (15 minutes preferred)
:•	Collect the data for a minimum contiguous 24- to 48-hour period, or one to two weeks if daily variation throughout the week is desired
:•	Collect bi-directional data (covers both directions).

'''Origin-Destination Data Collection Recommendations'''

Origin-destination (O-D) data is appropriate for some projects to be used for loading traffic demand data into a microsimulation model. O-D data is summarized in a matrix table that displays the number of trips (traffic demand) traveling from each origin (table row) to each destination (table column) in the study area. 

Due to the additional cost constraints of collecting the data through typical O-D collection methods (e.g., Bluetooth wireless readers, aerial observation, and third-party probe data providers), it is recommended that the analyst discuss the appropriateness of O-D data collection with MoDOT before proceeding. O-D data is especially useful for complex corridors where traffic patterns affect operations such as closely spaced intersections and certain freeway weaving segments.

'''Typical Data Needs for Software Tools'''

For transportation projects that utilize software tool analysis, it is important to understand analysis-specific data needs and input parameters that can often vary based on different analysis tools. Table 905.3.3.4 provides information about the typical traffic and roadway input parameters needed to utilize each analysis tool.
<center>
===Table 905.3.3.4, Typical Input Data for Different Analysis Types===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" rowspan="2" colspan="2" width=450|Input Data Category!!style="background:#BEBEBE" colspan="5" width=400| Traffic Analysis Tool
|-
!style="background:#BEBEBE" width=100 |HCS!! style="background:#BEBEBE" width=100 |SIDRA!! style="background:#BEBEBE" width=150| Synchro/SimTraffic!!style="background:#BEBEBE" width=100 |VISSIM!! style="background:#BEBEBE" width=100|HSM
|-
|rowspan="13 width=200|Traffic Operations and Control Characteristics|| align="left" width=250|Speed||width=100|	✔||width=100|	✔||width=150|	✔||width=100|	✔||width=100|
|-
|align="left"|Speed Limit||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Driver Behavior	||	||	||	||✔	||
|-
|align="left"|Parking||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Signs	||	||✔||		||✔	||
|-
|align="left"|Signals (Timing and Phasing)||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Detectors	||✔||	||	✔||	✔||	
|-
|align="left"|Intersection Control Type	||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Right/Left Turn Treatment||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Railroad Crossing	||	||	||✔	||✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Lane Restrictions	||	||	||	||✔||	
|-
|align="left"|Toll Facility	||	||	||	||✔||	
|-	
|align="left"|Ramp Metering	||	||	||	||✔||	
|-
|rowspan="9" width=200|Traffic Characteristics||align="left"|Demand||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Queue	||	||✔	||✔	||✔||	
|-
|align="left"|Capacity/Saturation Flow	||	||	||✔	||✔||	
|-
|align="left"|Pedestrian Counts	||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Bicycle Counts	||✔	||✔	||	||✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Bus & Transit	||✔||		||✔||	✔||
|-	
|align="left"|Fleet Characteristics	||✔	||✔	||✔	||✔	||
|-
|align="left"|Occupancy	||	||	||	||✔||	
|-	
|align="left"|Major Traffic Generators	||	||	||	||✔||		
|-
|rowspan="7" width=200|Roadway Characteristics||align="left"|Road Classification||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Cross Section||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Geometry	||	✔||	✔||	✔||	✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Roadside||✔	||	||	||✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Access Control	||✔	||	||	||✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Access Density	||✔	||	||	||✔||	<font color = "red">✔</font color = "red">
|-
|align="left"|Aerial Images	||✔||		||✔	||✔||
|-
|colspan="7" width=850 align="left"|'''Note:''' “HSM” is used to represent all HSM-based tools because all the HSM-based tools use similar data inputs. Additionally, <font color = "red">red check marks</font color = "red"> are used to distinguish safety tools (i.e., “HSM”) from operations analysis tools.
|}
</center>
<div id="Vehicle Classifications"></div>
'''Vehicle Classifications'''

FHWA's [https://www.fhwa.dot.gov/policyinformation/tmguide/tmg_fhwa_pl_17_003.pdf ''Traffic Monitoring Guide''] classifies all vehicles into 13 distinctly different categories. Figure 905.3.3.4.1 is a FHWA graphic of these 13 different categories.
[[image:905.3.3.4.1.jpg|thumb|775px|center|<center>'''Figure 905.3.3.4.1, FHWA Vehicle Classifications'''</center>]]
For the purposes of a traffic study, a heavy truck percentage provides the ratio of heavy trucks to overall vehicles on a roadway segment. MoDOT typically classifies vehicle proportions into the following six classifications for data collection purposes: 
:•	Motorcycles (FHWA Class 1)
:•	Passenger Cars (FHWA Class 2)
:•	Panel Trucks (i.e., Two-Axle, Four-Tire Single Unit Vehicles) (FHWA Class 3)
:•	Buses (FHWA Class 4)
:•	Single Unit Trucks (FHWA Classes 5, 6, 7)
:•	Combination Semi-Trailers (FHWA Classes 8 – 13). 

==905.3.3.5 [[media:905.3.3.5 TIA Data Collection Plan and Checklist.docx|Data Collection Plan and Checklist]]==
The data collection plan documents what, when, and how data will be collected.  The checklist will ensure that project deliverables, check-in points, and other considerations (including traffic data needs) are effectively communicated and documented throughout the project development process.

=905.3.4 Traffic Forecasting and Volume Development=
==905.3.4.1 Purpose==

EPG 905.3.4 details methodology options and best practices for developing traffic volume estimates and forecasts to be used in the planning for, and development of, transportation projects. Accurate and timely traffic volume estimates are crucial for ensuring the success of transportation projects through each stage, including transportation impact analyses (TIAs).

The following guidance provides information on best practices as identified through a review of both federal and state level guideline documents. It is important to note that this traffic volume development and forecasting information are predominantly the product of recommended guidelines rather than strict policy requirements. The National Cooperative Highway Research Program (NCHRP) 765 Report,'' Analytical Travel Forecasting Approaches for Project-Level Planning and Design'' (2014), summarizes this distinction:

:''“Project-level traffic forecasting has an underlying codification at the federal, state/MPO, and industry guideline level. In most cases, traffic forecasting procedures are the product of recommended guidelines rather than strict policy requirements. Thus, there is tremendous variation in practitioner procedures.
:''“At the federal level, traffic forecasting is required for air quality analysis, major investment projects and highway design projects undertaken by the federal government (Special Report 288, FHWA [22]). Traffic forecasting is also an integral part of several standard transportation processes, such as highway design—see the AASHTO Policy on Geometric Design (121), and the Highway Capacity Manual (21)."''

Underlying federal codification for traffic forecasts includes [https://www.law.cornell.edu/uscode/text/23/109 23 USC 109] and  [https://www.fhwa.dot.gov/legsregs/directives/fapg/cfr0625.htm 23 CFR 625] that state plans and specifications for National Highway System (NHS) projects shall provide for a facility that will “adequately serve the existing and planned future traffic of the highway in a manner that is conducive to safety, durability and economy of maintenance.”

==905.3.4.2 Background==

'''Traffic volumes''' describe the number of vehicles at a point on a roadway and are the most basic, readily understood output of the traffic forecasting and analysis processes. Traffic volume-based measures deal with the quantity of use of transportation facilities. The quantity can either be calculated at a specific point on a transportation network or between origins and destinations. Demand is associated with a specific time frame anywhere from 15 minutes to a 365-day annual period.

The NCHRP 765 Report provides the following summary for traffic volumes:
:''"Volumes can describe how the distribution and magnitude of demand change across different supply/demand scenarios. Volumes can describe throughput—a measure of the quantity of transportation activity that can be accommodated at a single point or multiple points on a transportation network. Volumes are also a critical input to assessments of congestion and economic and environmental impact.”''

'''Traffic forecasts''' are produced to assess transportation performance under different assumptions about transportation supply and demand. A traffic forecast uses existing traffic volume counts, historic traffic volume trends, travel demand model projections (if available), land use plans and socioeconomic data to predict traffic volumes and traffic flow patterns for a given year in the future. A traffic forecast is typically developed for a specific transportation project and is used for subsequent capacity analysis, geometric design and pavement design.

==905.3.4.3 Daily Traffic Volume Refinement==

After raw short-term traffic count data is collected, it should be processed by factoring it into Average Annual Daily Traffic (AADT) using factors that can be requested from MoDOT Transportation Planning Division. This process is accomplished using the following steps:
:'''1. Axle Correction Factor (ACF):''' If the count method includes vehicle axle data (i.e., tube counts), then an ACF should be used to adjust the axle counts into vehicle counts. An ACF is developed from classification counts by dividing the total number of vehicles by the total number of axles.
:'''2. Partial Weekday Traffic Count Adjustment:''' If partial weekday data was collected, then an adjustment factor is used to convert partial weekday traffic count data to 24-hour weekday daily traffic volume estimates, also known as Average Daily Traffic (ADT). The adjustment factor is representative of the percentage of 24-hour traffic volumes that typically occur on a weekday during the time range specified (e.g., 6 AM – 6 PM for a 12-hour traffic count). The adjustment factor usually varies by the type of roadway facility (e.g., interstate, US route, state highway, etc.).
:'''3. Average annual daily traffic (AADT):''' The ADT value is converted to AADT, which represents the average traffic volume throughout the year considering typical traffic conditions. A true AADT is developed by utilizing a full year of traffic count data, such as data generated from a permanent traffic counter. However, AADT can also be estimated with short-term traffic counts (usually a 24- to 48-hour period) using the following formula:

:::::::::::::AADT = ADT × Seasonal Adjustment Factor

==905.3.4.4 Design Hour Traffic Volume Refinement==

For most traffic analyses, AM and PM peak period (one or more hours) traffic volumes will be needed. Often design hour volumes are also needed, especially for design studies. The key phrases below are important to estimate the design hour characteristics of a location:

:• '''Design Hour:''' An hour with a traffic volume used for designing the geometric and control elements of a facility. The design hour selected will allow the designed facility to accommodate peak hour traffic during most days. The Highway Performance Monitoring System considers the hour corresponding to the 30th highest hourly volume of the year as the design hour. In the absence of continuous counters to determine the 30th highest hourly volume of the year, local jurisdictions and/or Metropolitan Planning Organizations (MPOs) can adjust their design hour based on local facility-specific traffic conditions (refer to Page 22 of the [https://www.fhwa.dot.gov/policyinformation/pubs/pl18027_traffic_data_pocket_guide.pdf ''FHWA Traffic Data Computation Method Pocket Guide'')].

:• '''Design hourly volume (DHV):''' The volume of vehicles that travel through a segment of roadway during the design hour. The DHV is used for making roadway structural and capacity design decisions in the design year because traffic volume varies by hour and from day to day throughout the year. The formula for calculating the DHV using a design hour factor (K) is:

::::::::::::DHV = K × AADT

:• '''Design Hour Factor/K Factor:''' The proportion of the AADT that occurs during the design hour. K-factors are typically estimated to be between 8% and 12%, with lower K-factors generally occurring on primary routes and higher K-values occurring on secondary routes. In the absence of available traffic data, a planning level estimate of K=10% is sometimes assumed (for high level, sketch planning ONLY). For further information about the typical weekday and weekend hourly distribution of traffic volumes, refer to Figures 1.1 through 1.5 of FHWA’s [https://www.fhwa.dot.gov/tpm/guidance/hif18040.pdf ''Measures for Congestion, Reliability, and Freight Step-by-Step Metric Calculation Procedures''] (Published June 2018).
::::::::::::K = DHV/AADT

:• '''Peak Hour Directional Split (D Factor):''' The percentage of the total two-way peak hour traffic that occurs in the dominantly traveled direction.

==905.3.4.5 Traffic Volume Balancing==

Raw traffic volumes along a corridor will have inconsistencies when initially tabulated. These differences in Base Year traffic volumes are frequently the result of the presence of other intersecting roadways along a corridor or traffic data collection method variations (e.g., data collected on different days, counter error, unexpected traffic incidents, etc.). Future Year traffic volumes will frequently have inconsistencies due to varying growth rates applied along the corridor.

It is generally beneficial for a traffic forecast to “balance” the traffic volumes, which refers to the process of eliminating the traffic volume difference between multiple points completely. The NCHRP 765 states that “balancing helps to 'clean' traffic volume data by tempering the effects of outliers and counting errors.” 

For certain forecasts or project locations, balancing might not affect the overall quality of the traffic forecast. However, balancing is needed for microsimulation models or for any analysis type where the difference between the traffic volumes of two given points does not match their predicted traffic volumes for intersection roadways or driveways. Also, it is important to balance traffic volumes when an Origin-Destination (O-D) trip table matrix will be used for subsequent capacity analysis. Balanced traffic volumes will result in a faster convergence when the O-D matrix estimation is applied because the matrix estimation algorithms tend to fluctuate when attempting to match conflicting goals.

The following methods are available to balance traffic forecast volumes are summarized in Table 905.3.4.5. Engineering judgement is recommended to determine which method is appropriate based on traffic volume data available.
<center>
===Table 905.3.4.5,  Typical Traffic Volume Balancing===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width=125|Method!!style="background:#BEBEBE" width=400| Description!!style="background:#BEBEBE" width=150| Pros!!style="background:#BEBEBE" width=200|Cons
|-
|'''Split the Difference'''||align="left"|Add half of the total link imbalance to the lower volume intersection and subtract the remainder of the total link imbalance to the higher volume intersection.||Realistic results||Time consuming, especially if multiple intersections are completed
|-
|'''Higher Volume Distributed'''||align="left"|Use the higher volume from one intersection to override the lower volume of the adjacent intersection and then distribute the volume difference based on the existing turning movement count distributions.||Realistic results||Time consuming
|-
|'''Higher Volume Through'''||align="left"|Use the highest volume and carry it through the other locations adding the excess traffic only to the through movements.||Ease of calculations||Conservatively high through volumes relative to turning movement volumes at lower volume intersections.
|-
|'''Spreadsheet Link Volume Forcing'''||align="left"|Use the link volume forcing option of the NCHRP 255 spreadsheet to automatically balance/smooth volumes. This method should be used with caution and does not always produce the desired outcome if convergence cannot be reached.||Automated calculations||May not produce all desired results
|-
|'''Combination'''||align="left"|A combination of all or some of the other methods. For example, the NCHRP Override process may be used first to get the volumes closer to being balanced, and then a combination of the Higher Volume Distributed method at the internal intersections and the Higher Volume Through at the network termini could be used.||Realistic results||Time consuming
|}
</center>

'''General Balancing Rules of Thumb:'''

General “rules of thumb” to help the analyst make sound decisions for balancing traffic volume data include:
:• '''Understand data deficiencies:''' Understand the locations of where data collected is more likely accurate, defensible, and verifiable by multiple sources. Rely on those data sources to carry forward traffic volumes during balancing.
:• '''Balance the project’s needs between realistic results and efficient calculations:''' If a high-level analysis is being completed and it is acceptable to maintain conservatively high volumes in certain locations, then perhaps the analyst could consider using the “higher volume through” method. That method in high-level planning would not be time consuming relative to the analysis needs at that stage. If the analysis level is preliminary engineering and greater detail is needed, then perhaps a combination of various methods is needed where the analyst can start with one method and iteratively adjust when comparing to other methods.
:• '''Determine level of error and if new data is needed:''' If the volumes being balanced are 10% or more off, then the analyst should revisit the data and determine if errors have been made in the data processing or the traffic forecast. If the data is inaccurate, then consider collecting additional data.

==905.3.4.6 Traffic Forecast Types and Tools==

There are two general types of traffic forecasts: planning-level forecasts and project-level forecasts.

:1. '''Planning-level forecasts''' typically do not require current traffic data to be collected. If traffic data is collected, it is usually limited to just roadway segment data with no turning movement counts required. Planning-level forecasts are either completed (1) during long range transportation planning for any given project or regional analysis (at least 20-year horizon required by FHWA for MPO planning), or (2) during the project planning and programming for a “preservation” project. A “preservation” project includes roadway resurfacing, reconditioning, pavement replacement, roadway maintenance or bridge rehabilitation/replacement. Regional travel demand models and historic AADT growth rates are typically used for planning-level forecasts.
:2. '''Project-level forecasts''' require both turning movement count and roadway segment traffic data to be collected. Project-level forecasts are completed during the project planning and programming for widening, new location, bridge replacement (if capacity changes are made) and new roadway capacity or new development-based projects. Regional travel demand models, historic AADT growth rates, turning movement analyses and new development trip generation analyses (as needed) are typically used for project-level forecasts.

'''Traffic Forecasting Tool(s):''' In coordination with understanding the applicable forecast type, it is important to understand the most appropriate tool to use for a traffic forecast, given factors such as the transportation project needs, size and complexity of the project, and resources available. The NCHRP 765 lists the most common forecasting tools as summarized in Table 905.3.4.6.

<center>
===Table 905.3.4.6, Common Traffic Forecasting Tools===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width=125|Tool!!style="background:#BEBEBE" width=300| Description!!style="background:#BEBEBE" width=250| When to Apply!!style="background:#BEBEBE" width=150|Potential Shortcomings
|-
|'''Growth Rate'''||align="left"|Focuses on extending the observed traffic growth patterns at a given location to a future year.||align="left" rowspan="3"|• No travel demand model is available<br/>• Historic growth in the study area is stable and expected to remain that way in the future<br/>• Project is small in size and complexity<br/>• Resources and/or time in schedule is unavailable for more in-depth analyses||align="left" rowspan="3"|These methods do not naturally focus the constraining factor of a roadway’s capacity.
|-
|'''Trend Line Analysis'''||align="left"|Review and analyze existing, historic AADT data to calculate trend line growth rates for medium-term and long-term timeframes (often 10 to 20 years in the past). Outlier data points will be eliminated from the analysis as appropriate.
|-
|'''Time-Series Analysis'''||align="left"|Estimates traffic volumes as a function of time and, perhaps, a small set of explanatory variables.
|-
|'''Turning Movement Analysis'''||align="left"|The process of analyzing, refining, and balancing turning movement count data for intersections studied as part of a traffic forecast.||align="left"|• Daily intersection turning movement counts<br/>• Design hour intersection turning movements volumes and factors||align="left"|Does not focus on estimating base year to future year growth. Is typically done in conjunction with other tools.
|-
|'''Travel Demand Model'''||align="left"|A series of mathematical equations that represent how choices are made when people travel. A travel demand model combines a network (supply) with population and employment by location (demand for travel).<br/>A travel demand model can encompass roadway networks and population/employment for an entire metropolitan region.||align="left"|• Travel demand model is available for the region studied<br/>• Growth in the study area is anticipated to change at varying rates relative to historic growth<br/>• Resources and project schedule is available for model utilization||align="left"|Is not always appropriate for projects of small size and complexity (e.g., small road bridge replacement or site development with no roadway network forecast needed)
|-
|'''Traffic Simulation Model'''||align="left"|Traffic simulation models are designed to emulate the behavior of traffic in a transportation network over time and space to predict system performance.||align="left"|When the quantification of peak hour volumes, capacity, Level of Service, travel times, or other measures of effectiveness (MOEs) are needed in addition to daily forecasted volumes.||align="left"|Is not a standalone forecasting tool. Is typically applied for an in-depth capacity analysis after forecasted traffic volumes have been determined.
|}
</center>

Utilizing a travel demand model is the preferred tool for developing a traffic forecast if a travel demand model is available for a study area. It is important to confirm with the MPO or appropriate local entity that the regional travel demand model has been approved by the region before utilization of the model. Regions such as St. Louis and Kansas City are usually robust in consistently approving model updates, but always verify from the appropriate sources before using.

Growth rates, trend line analyses, and time-series analyses are all similar and have some overlap. The differences are that the emphasis points for each tool are “constant growth rate over time” (growth rate tool), historic traffic volume data regression lines (trend line analysis), and extrapolating trends over a period of time that can be either constant or variable in growth (time-series analysis).

Turning movement analyses are typically completed in conjunction with other tools and traffic simulation models are often completed for traffic capacity analyses, which are developed subsequently after traffic forecasts.

==905.3.4.7 Forecast Application==

The development of a traffic forecast includes the following steps:
:1. Collect and Review Data
::a. Collect data from the existing available data sources, including but not limited to:
::::i. AADT for the past 10 to 20 years
::::ii. Other pre-existing traffic count data
::::iii. Previous traffic forecasts for the project and other relevant forecasts in the general area
::::iv. Information from available plans, including local land use plans, relevant demographic data and regional transportation plans
::::v. Consultation with local planners, engineers and other appropriate parties regarding traffic patterns, pending development plans, land use plans and historic growth
::::vi. On-site field investigation.
::b. Develop historic AADT rates for long- and mid-term (approximately 20 and 10 years, respectively) historic growth. Look for natural breaks in the data as well as data anomalies.
::c. Collect project-specific traffic count data as needed
::d. Convert raw project-specific daily count data to AADT estimates using seasonality and other factors
:2. Develop Base Year No-Build (i.e., existing no build) volumes. The scenario may include intersection quadrant turning movements, design data (K & D factors, heavy truck percentages), and be balanced unless otherwise specified.
:3. Utilize Travel Demand Model (when available)
::a. Review the Model Validation – Compare the existing model traffic volumes to actual project AADT estimates
::b. Review the Transportation Network – Ensure accuracy of the model base year network relative to the actual transportation network. Also, check that all fiscally constrained MTP projects as identified by an MPO are included in the model’s future year network
::c. Calculate model growth. Per NCHRP 765, there are two methods, which are displayed in Table 905.3.4.7. It is advised that a preferred method be selected by reviewing the results from both methods and evaluating them within the context of existing traffic volumes and turning movements.

<center>
===Table 905.3.4.7, Model Growth Calculation Methods===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width=125|Method!!style="background:#BEBEBE" width=250| Description!!style="background:#BEBEBE" width=300| Pros!!style="background:#BEBEBE" width=200|Cons
|-
|'''Difference Method'''||align="left"|Applies the difference between the base year turning movement count and the base year model assignment to the future year model turning movement assignment. '''Formula:'''<br/><br/><center>FF<sub>di</sub> = FA<sub>i</sub> + (BC<sub>i</sub> – BA<sub>i</sub>)</center><br/>FF<sub>di</sub> = future year forecast volume for turning movement i,<br/>FA<sub>i</sub> = future year model assignment,<br/>BC<sub>i</sub> = base year count,<br/>BA<sub>i</sub> = base year model assignment||align="left"|Results are not easily inflated by nearby land use changes.||align="left"|Two items must both be accurate:<br/>1. Model assignment (must be calibrated very closely to traffic count data)<br/>2. The relationship between the base year and future year model assignments must be reasonable
|-
|'''Ratio Method'''||align="left"|Utilizes a traffic growth factor by dividing the future year model volume by the base year model volume. '''Formula:'''<br/><br/><center>FF<sub>ri</sub> = BC<sub>i</sub> * (FA<sub>i</sub>/BA<sub>i</sub>)</center><br/>FF<sub>ri</sub> = future year forecast volume for turning movement i,<br/>BC<sub>i</sub> = base year count,<br/>FA<sub>i</sub> = future year model assignment,<br/>BA<sub>i</sub> = base year model assignment||align="left"|Unlike the difference method, the ratio method can work if model volumes assigned do not calibrate accurately with count data (within reason).<br/>The ratio method is primarily focused on the relationship between the base year and future year model assignments. (The NCHRP 765 states that the ratio method is better than the difference method because it is less susceptible to inaccurate model assignment, especially over a long time horizon.)||align="left"|Drastic changes in model assignment from base year to future year (from land use changes, for instance) or low model volumes could produce unreasonable growth.
|-
|colspan="4" align="left"|'''Note:''' NCHRP 255 discussed averaging the results from the ratio and difference methods as a means to reduce the extremes that may be reached by either the ratio or difference method. However, NCHRP 765 supplants NCHRP 255 and advises that the average method not be used because averaging will reduce the accuracy of one method or the other.
|}
</center>

:4. Develop Future Year No-Build Forecast – Apply both model and historic AADT growth to Base Year No-Build traffic volumes to estimate Future Year No-Build traffic volumes. Review and adjust traffic volumes based on knowledge of future land use, professional judgement and to maintain reasonable corridor traffic volume balancing.
:5. Develop Base Year and Future Year Build Forecasts – Utilize the travel demand model (when available) to determine diversion and/or growth on the transportation network in the study area. Apply the diversion to the No-Build scenarios or the growth to the base scenarios to estimate Build scenario volumes. Review and adjust traffic volumes based on knowledge of network changes, professional judgement and to maintain reasonable corridor traffic volume balancing.
:6. Coordinate and provide a review period with all appropriate parties during forecast development to ensure that reasonable forecast assumptions are made. Refer to the MoDOT TIA Guidance Methods and Assumptions template.
:7. Document the forecast using a combination of figure diagrams and a report to explain all assumptions made. Refer to the MoDOT Methods and Assumptions Report Checklist and the Data Collection Plan and Checklist.

==905.3.4.8 Forecast for a TIA==

TIAs are engineering studies that compare before and after traffic conditions on road networks due to proposed land use changes. EPG 905.3.4.8 Forecast for a TIA focuses on project-level forecasts that are primarily developed to support the creation of TIAs. The forecasting scoping and application steps of a TIA forecast will be similar to the steps listed above. However, additional focus should be provided to identify potential development traffic to add to the forecast. Figure 905.3.4.8.1 guides the user into whether a development should be added to the forecast.
<div id="Figure 905.3.4.8.1,"></div>
[[image:905.3.4.8.1.jpg|center|800px|thumb|'''<center>Figure 905.3.4.8.1, Identifying Potential Developments for Forecast'''</center>]]

To determine the impact that proposed development(s) will have on future traffic conditions, it is important to identify how development trips will be generated, distributed, and assigned on the roadway network. The following five steps are used to make this determination:

:1. '''Assess Trip Generation Potential:''' The most commonly accepted source for trip generation data on land use development is the [https://www.ite.org/ Institute of Transportation Engineers] (ITE) ''Trip Generation Manual''. The ITE ''Trip Generation Manual'' includes trip generation characteristics of a wide variety of land use types. Land use types include port and terminal, industrial, residential, lodging, recreational, institutional, medical, office, retail, and services. Trip generation characteristics for these land use types were determined based on studies completed between the years 1980 and 2017.

:Once the land use category is selected in the ITE ''Trip Generation Manual'', an “independent variable” that the study is based off is selected. Independent variables usually include items such as square feet of development, number of employees, acres of land parcel(s), number of dwelling units, etc. The time period is then selected, which often includes the AM peak, the PM peak hour, weekday totals, and sometimes, weekend days. Also, some land use types can allow you to select a “setting/location” type, but often times it will be default to only one option, such as “General Urban/Suburban” for single-family detached housing.

:The ITE ''Trip Generation Manual'' provides a web-based app (Figure 905.3.4.8.2 provides example of interface) to determine these study settings and to input the quantity of the project-specific independent variable to calculate an estimated, raw number of trips generated. The number of trips will be calculated using either a fitted curve equation or an average trip rate. In order to determine which method of trip generation calculation is relevant for the project, the reasonableness of the study’s data sample attributes (e.g., R<sup>2</sup>, standard deviation, and sample size) must be reviewed.

[[image:905.3.4.8.2.jpg|center|975px|thumb|'''<center>Figure 905.3.4.8.2, Layout of ITE ''Trip Generation'', Web-Based App'''</center>]]


:Figure 905.3.4.8.3 displays a decision-making flow chart from the ITE ''Trip Generation Handbook'', 3<sup>rd</sup> Edition, to help determine what trip generation method to use.

[[image:905.3.4.8.3.jpg|center|800px|thumb|'''<center>Figure 905.3.4.8.3, Selecting Appropriate Method to Estimate Trips Generated'''<br/>Source:  Figure 4.2 of ITE ''Trip Generation Handbook'', 3<sup>rd</sup> Edition</center>]]

:2. '''Mode Split:''' The selection of trip mode choices should be informed by the availability of nearby transit and bicycle/pedestrian infrastructure, a review of available multi-modal count data, and coordination with local planning and engineering partners. Mode choice assumptions should be well documented in the final TIA.
:3. '''Estimate the Generated Trip Types:''' The type of trips generated should be considered as part of the trip generation process. The total trips generated are determined and then the internal trips, pass-by trips and diverted link trips are subtracted to calculate new trips.
::a. '''New Trips:''' New trips are “primary trips” that are made for the specific purpose of visiting the development. This trip type usually travels from an origin outside of the development to the development and then returns back to the origin.
::b. '''Internal Trips:''' An internal trip is a trip that both originates and ends within the development. Internal trips rates will vary depending on the proposed land use type, size, and the context of the surrounding area. For instance, a mixed-use development in an urban area would likely have a higher internal trip rate than a typical commercial development in a rural area.
::It is important to use internal capture calculations very cautiously. Internal Capture is often applicable to sites or subdivisions of sites that are accessible without using or crossing public streets. Internal Capture rates may be estimated using an [http://onlinepubs.trb.org/onlinepubs/nchrp/nchrp_rpt_684.xlsx automated worksheet tool in the NCHRP 684].
::When using this spreadsheet, it is advised:
:::• That transit or non-motorized splits should not be used unless otherwise justified and approved.
:::• That vehicle occupancy should be “1.1” unless local data is available.
:::• The Walking Distances between land uses should be 1000 ft. or the calculated maximum distance between a given pair of land use categories in the proposed site.
::The internal capture reduction should be applied before the pass-by trips are calculated.
::c. '''Pass-By Trips:''' trips that are made as intermediate trips on the way from an origin to a primary trip destination and do not require a route diversion from another roadway. Pass-by trips are new at the site driveway but are not new on the adjacent roadway.
::It is recommended that pass-by trip percentages should only be applied to land uses numbered in the 800s (retail) and 900s (services). For multi-use developments, pass-by percentages should be applied to the retail component only. Total pass-by trips (sum of entering and exiting) should not exceed 10% of the volume on the adjacent street.
::d. '''Diverted Link Trips:''' Diverted link trips are the number of trips attracted from the existing traffic and require a route diversion from one roadway to another to reach the development. It is advised that:
:::• Diverted link trips should only be estimated in a TIA if reliable data reporting the percentage distribution of the three types of trips (primary, pass-by, and diverted link trips) are available for the land use being considered, and
:::• The travel routes for diverted trips can be clearly established.
::If these conditions cannot be met, the analyst should treat all non-pass-by trips as primary trips.
:4. '''Trip Distribution:''' Typically, site-related traffic is distributed onto the transportation network by using existing traffic flow patterns. Other distribution methods that revolve around the gravity model or socioeconomic data may be considered, but typically those methods are completed to supplement the Existing Traffic Pattern method. The Gravity Model and Socioeconomic Data methods focus on travel patterns from a regional and sub-regional perspective and are too coarse to exclusively be used for site development trips without accompanying traffic patterns based on count data. These methods are summarized below, including a Table 905.3.4.8.4 comparison.

<center>
===Table 905.3.4.8.4, Typical Trip Distribution Methods===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width=125|Method!!style="background:#BEBEBE" width=225| Description!!style="background:#BEBEBE" width=225|Method Application  !!style="background:#BEBEBE" width=225| Required Data!!style="background:#BEBEBE" width=150| When to Use
|-
|'''Existing Traffic Patterns'''||align="left"|Derives trip distribution percentages based on existing data at sites that are comparable to the subject development.||align="left"|The ITE ''Trip Generation Manual'' and the existing traffic counts, combined with local knowledge of traffic patterns and land use||align="left"|• Traffic volume segment and turning movement count data that is representative of current traffic conditions.<br/>• ITE ''Trip Generation Manual''||align="left"|Use for most TIA projects
|-
|'''Gravity Model'''||align="left"|Estimates trip distribution based on characteristics of the land-use patterns within the vicinity of the subject development.||align="left"|The gravity model formula (is usually applied through a travel demand model, though it can be applied manually)||rowspan="2" align="left"|• Land use socioeconomic data that is segmented into geographic zones of homogeneous land use types.<br/>• Regional travel demand models are frequently the tool that is utilized for these analysis methods.<br/>• US Census data to verify local socioeconomic data used.||rowspan="2" align="left"|Use when it is important to support the Existing Traffic Pattern method with estimates of traffic pattern movements from a regional perspective
|-
|'''Socioeconomic Data'''||align="left"|Uses population and employment data to estimate trip distribution for the study area.||align="left"|Various application methods (e.g., population data as a surrogate for retail trips, market area analysis, etc.)
|}
</center>

::a. '''Existing Traffic Patterns:''' Existing traffic count data is analyzed to determine current daily and peak hour traffic patterns on major study area roads near the traffic site. The ITE ''Trip Generation Manual'' provides the estimated directional distribution of trips for AM and PM peak hours and overall daily traffic. Figure 905.3.4.8.5 shows the circled directional distribution percentages.

[[image:905.3.4.8.5.jpg|center|800px|thumb|'''<center>Figure 905.3.4.8.5, Directional Distribution in ITE Trip Generation, Web-Based App'''</center>]]

::The ITE ''Trip Generation Manual'' and the existing traffic counts, combined with local knowledge of traffic patterns and land use as well as professional judgement, are then used to determine the traffic distribution percentages to and from the site development. Figure 905.3.4.8.6 shows the transportation network distribution of site-related trips.

[[image:905.3.4.8.6.jpg|center|775px|thumb|'''<center>Figure 905.3.4.8.6, Site Trip Distribution onto Road Network'''</center>]]


::b. '''Gravity Model Method:''' The gravity model method partitions land use into zones of homogenous land use attributes (i.e., households and employment type) and determines the number of trips between each zone. Trips entering a zone are known as “attracted” trips while trips leaving a zone are “produced” trips. A zonal cumulative analysis based on a gravity model formula is used to determine the distribution of trip attractions and productions. Zones with larger trips generated will attract and produce more trips than smaller zones on a relative basis. Zones with less impedance (usually measured by distance or travel time) between them will have more trips distributed between them. The gravity model formula is:

[[image:905.3.4.8 gravity.jpg|center|225px]]

::where T<sub>ij</sub> = the forecast flow produced by zone ''i'' and attracted to zone ''j''
::P<sub>i</sub> = the forecast number of trips produced by zone ''i''
::A<sub>j</sub> = the forecast number of trips attracted to zone ''j''
::d<sub>ij</sub> = the impedance between zone ''i'' and zone ''j''
::f(d<sub>ij</sub>) = the friction factor between zone'' i'' and zone'' j''

::The gravity model can be applied iteratively and can be constrained to productions or attractions. The gravity model trip distribution process can be applied manually or through the application of a regional travel demand model.
::c. '''Socioeconomic Data:''' this method can be applied if an extensive database of socioeconomic data exists for the study area. This method would entail using population and employment data to estimate trip distribution for the study area. A regional travel demand model could provide socioeconomic data estimates developed by an MPO.

:5. '''Trip Assignment:''' Traffic volumes to and from a future development are assigned to specific roadways either manually or using a travel demand model for larger studies. To create the trip assignment, the trip percentage distribution is applied to the trip generation for the assignment of new (primary), pass-by and diverted link site trips. Summing up the background, new (primary), pass-by and diverted link trips results in the final total trip assignment.
:The assignment of each of the components of site trips (new (primary), pass-by, and diverted link) is recommended to be calculated and displayed on separate flow diagrams. Calculations are typically performed in a spreadsheet. A step-by-step example with exhibits is in [[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to Volume Development.docx|Accompaniment to Volume Development]].
::a. '''New (Primary) Trips:''' The assignment of new (primary) trips for each turning movement is calculated by multiplying the previously determined number of directional new (primary) trips (trip generation) by the new (primary) distribution percentage applicable to that movement.
::b. '''Pass-by Trips:''' The assignment of pass-by trips for each turning movement is calculated by multiplying the previously determined number of directional pass-by trips (trip generation) by the pass-by distribution percentage applicable to that movement. Typically, pass-by trips should not exceed 5 to 10 percent of the traffic volumes on the adjacent roadways. Also, the egress and ingress pass-by volumes usually are equal.
::c. '''Diverted Link Trips:''' The assignment of diverted link trips for each turning movement is calculated by multiplying the previously determined number of directional diverted link trips (trip generation) by the diverted link distribution percentage applicable to that movement. Typically, the egress and ingress diverted link volumes should be equal.
::d.''' Site Trip Summation:''' Each of the components of site trips are then summed for each vehicle movement and displayed in a flow diagram of total site trips as shown in Figure 905.3.4.8.7 (all example exhibits displayed in [[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to Volume Development.docx|Accompaniment to Volume Development]]).
[[image:905.3.4.8.7.jpg|center|775px|thumb|'''<center>Figure 905.3.4.8.7, Total Site Trip Assignment'''</center>]]

::e. '''Site Trips with Background Traffic:''' The total site trips are then combined with Background Traffic to create Background plus Site trips as shown in Figure 905.3.4.8.8 (all example exhibits displayed in [[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to Volume Development.docx|Accompaniment to Volume Development]]).
[[image:905.3.4.8.8.jpg|center|775px|thumb|'''<center>Figure 905.3.4.8.8, Site Trips with Total Traffic'''</center>]]

::In the diagram example above, Road Y would have a total of 140 southbound through trips after subtracting 10 trips lost from what was originally 150 background trips.

=905.3.5 Traffic Analysis Tools=
As discussed in [[#905.3.2 Methodology and Scoping|EPG 905.3.2 Methodology and Scoping]], each traffic analysis tool varies in analysis function and are useful and effective in understanding and assessing transportation needs for projects. EPG 905.3.5 Traffic Analysis Tools includes a review of existing traffic analysis tools and common modeling concerns, parameters, and best practices that are applicable for each tool. This article is subdivided into:

:• [[#905.3.5.1 Common Analysis Tool Input Parameters|EPG 905.3.5.1 Common Analysis Tool Input Parameters]]: common input parameters that are applicable to most analysis software tools.
:• [[#905.3.5.2. Static/Deterministic Models|EPG 905.3.5.2. Static/Deterministic Models]]: HCS, SIDRA, and Synchro
:• [[#905.3.5.3 Microsimulation Models|EPG 905.3.5.3 Microsimulation Models]]: SimTraffic and VISSIM
:• [[#905.3.5.4 Other Software|EPG 905.3.5.4 Other Software]]
:• [[#905.3.5.5 Model Templates|EPG 905.3.5.5 Model Templates]]
:• [[#905.3.5.6 Review Checklists|EPG 905.3.5.6 Review Checklists]].

==905.3.5.1 Common Analysis Tool Input Parameters==
Table 905.3.5.1.1 displays common parameters that are generally applicable to most traffic analysis tools. All parameters in EPG 905.3 Transportation Impact Analysis are suggestions. It is important to use field data, if available, unless otherwise specified. The MoDOT suggested parameter values can be applied when no field data is available, to verify field data, and/or to replace field data if the data is unreasonable. The traffic analysis tools included in EPG 905.3 Transportation Impact Analysis have a standard set of input parameters.

The list of parameters in EPG 905.3 Transportation Impact Analysis are not exhaustive (for a full list of parameters, refer to each individual analysis tool’s user guide), but focus on key traffic analysis parameters with specific MoDOT guidance for proper application.

<center>
===Table 905.3.5.1.1, Common Parameters for Traffic Analysis Tools (When Field Data is Not Available)===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE" width="150"|Parameter!!style="background:#BEBEBE" width="300"| Parameter Description!!style="background:#BEBEBE" width="275"|Suggested/Typical Value(s)
|-
|width="150"|Cycle Length (sec)||width="300"|Total time required to service all competing traffic movements at a signalized intersection.||width="300"|'''Typical Maximum Value:''' 140 seconds<br/>'''Absolute Maximum Value:''' 240 seconds<br/>'''Coordinated Corridors:''' Match corridor cycle length
|-
|Offset (sec)||Number of seconds that the reference (coordinated) phase lags after the master offset.||As long as a consistent reference phase is used, this should be equal to the travel time in the reference phase direction from the master intersection to the subject intersection.
|-
|Link Speed (mph)||The speed limit or safe, legal speed anticipated on an approach or segment.||'''Typical Links:''' Enter the speed limit or safe, legal speed anticipated at approach.<br/>'''Typical Ramps:''' 35 mph<br/>'''Loop Ramps:''' 25 mph<br/>'''Driveways:''' 25 mph
|-
|Storage Length (ft)||The storage bay length does not include the taper length. (In Synchro, this is a separate measurement that can be specified in the Simulation Settings table.)||Round user input up to the nearest 25 ft. increment (e.g., round 160 ft. up to 175 ft.).<br/>This allows for a conservatively higher estimate to account for slight small inaccuracies in field data (319 ft. vs. 324 ft., for instance) and to account for the length of vehicles (assume the length of one vehicle per 25 ft. of storage length).
|-
|Peak Hour Factor (PHF)||Peak hour traffic volumes are divided by the PHF to calculate the traffic flow rate during the busiest 15-minute period during the hour.||'''Current Conditions:''' Use traffic data, if available, to calculate PHF.<br/>'''Current Conditions with no data and Future Conditions:''' Use default value of 0.92
|-
|Conflicting Pedestrians (#/hr)||colspan="2"|Enter the number of pedestrian calls per hour that conflict with permitted turn movements (do NOT enter all pedestrians activating this phase unless there is only one pedestrian per ped call).
|-
|Conflicting Bicycles (#/hr)||colspan="2"|Enter the number of bicycles that conflict with right turns. Enter 0 if bicycles cross the right-turn traffic ahead of the intersection.
|-
|Bus Blockages (#/hr)||The number of local buses that will block traffic flow in as it enters or exits an intersection. The factor is applied by lane group and not the overall intersection as a whole.||'''CBD Bus Stop:''' 12 buses/hr<br/>'''Non-CBD Bus Stop:''' 2 buses/hr<br/>'''Note:''' Increasing bus blockage values will decrease the bus blockage factor and, consequently, decrease the saturated flow rate. However, this decrease can be gradual, as an increase of 2 to 12 buses stopped per hour (the typical difference in non-CBD vs. CBD stops) on a one-lane lane group would only lower the saturated flow rate by 4%.
|-
|Minimum Split (sec)||colspan="2"|'''Signal Plan:''' User-defined value<br/>'''Calculation:''' Minimum Initial Green Time + Yellow Time + All-Red Time '''OR'''<br/>Walk Time + Flash Don’t Walk + Yellow Time + All-Red Time (whichever is larger)
|-
|width=200|Total Split (sec)||colspan="2" width=550|'''Signal Plan:''' User-defined value<br/>'''Calculation:''' Sum of maximum splits for movement, includes Yellow + All-Red
|-
|Walk Time (sec)||colspan="2"|'''Actuated Signal:''' 7 sec<br/>'''Pre-Timed Signal:''' Green interval minus “Flash Don’t Walk”
|-
|Flash Don’t Walk (sec)||colspan="2"|Based on 3.5 ft/s walking speed (from curb to curb)
|-
|Yellow and All-Red Times||colspan="2"|Refer to Table 905.3.5.1.2 and Table 905.3.5.1.3.
|}
</center>

<center>

===Table 905.3.5.1.2, Duration of Minimum Yellow Change Interval===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width="250"|Approach Speed (mph)!!style="background:#BEBEBE" width="300"| Minimum Yellow Change<sup>1</sup> (sec)
|-
|25|||3.0<sup>2</sup>
|-
|30||3.2
|-
|35||3.6
|-
|40||3.9
|-
|45||4.3
|-
|50||4.7
|-
|55||5.0
|-
|60||5.4
|-
|colspan=2 width="555" align="left"|'''Note:''' table based on Exhibit 6-2 from the NCHRP 812.
<br/><sup>'''1'''</sup> Based on negligible approach grades. A 0.1 second increase should be made for every 1% of downgrade and a 0.1 second decrease should be made for every 1% of upgrade.<br/><sup>'''2'''</sup> The NCHRP 812 recommends that a minimum of 3 seconds should be used.
|}
</center>

<center>
===Table 905.3.5.1.3, Duration of Red Clearance Interval===
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" width="250" rowspan="3"|Approach Speed (mph)!!style="background:#BEBEBE" width="500" colspan="5"|Red Clearance (sec)
|-
!style="background:#BEBEBE" width="500" colspan="5"|Width of Intersection (ft)
|-
!style="background:#BEBEBE"| 30 !!style="background:#BEBEBE"|50 !!style="background:#BEBEBE"|70 !!style="background:#BEBEBE"|90!!style="background:#BEBEBE"| 110
|-
|25||0.4||0.9||1.5||2.0||2.5
|-
|30||0.1||0.6||1.0||1.5||2.0
|-
|35||0.0||0.4||0.8||1.1||1.5
|-
|40||0.0||0.2||0.5||0.9||1.2
|-
|45||0.0||0.1||0.4||0.7||1.0
|-
|50||0.0||0.0||0.2||0.5||0.8
|-
|55||0.0||0.0||0.1||0.4||0.6
|-
|60||0.0||0.0||0.0||0.2||0.5
|-
|colspan="6" align="left" width=755|'''Note:''' table based on Exhibit 6-3 from the NCHRP 812.
|}
</center>

==905.3.5.2. Static/Deterministic Models==

Deterministic models use static formulas to determine the relationships of flow, speed, and density of the traffic stream. These models are ideal for analyzing isolated/small scale facilities and freeway/highway facility segments. Their strengths include their abilities to quickly predict capacity, density, speed, delay, and queuing. A key limitation includes their lack of ability to analyze network or system effects on travel flow. Common deterministic tools that will be summarized in EPG 905.3.5.2. Static/Deterministic Models include HCS, SIDRA, and Synchro.

===905.3.5.2.1 HCS===

Highway Capacity Software 7 (HCS7) is a traffic analysis software package which contains a series of modules that implement the procedures and methodologies outlined in the HCM, 6<sup>th</sup> Edition. HCS7 can be used to analyze the following modules and sub-modules:
::• Streets
:::o Streets (includes signalized intersections)
:::o Reliability
::• Stop
:::o All-Way Stop Controlled (AWSC)
:::o Two-Way Stop Controlled (TWSC)
::• Roundabouts
::• Highways
:::o Two-Lane
:::o Multilane
::• Freeways
:::o Freeways
:::::▪ Basic (Segment)
:::::▪ Merge
:::::▪ Diverge
:::::▪ Weaving
:::::▪ Facility
:::o Reliability
::• Tools.

HCS7 is a widely accepted tool that can be used quickly and easily with simplistic parameters and inputs. Since HCS7 is limited to the deterministic methodologies of HCM6, it is strictly equation-based and does not have the ability to analyze oversaturated conditions where queues dynamically interact between closely spaced network elements such as ramps and intersections. The strengths and limitations of HCS7 should be considered when determining an appropriate analysis tool.

HCS7 utilizes standard HCM6 traffic data parameters and inputs. Refer to Table 905.3.5.2.1.1 and subsequent module summaries for guidance on standard HCS7 traffic and phasing parameters and inputs. It is important to note that the Freeway and Reliability modules are covered in greater detail than the other modules because of the benefit for using those modules for transportation projects relative to other modules (e.g., Synchro would often times be used for signalized intersections, but HCS would be chosen over Synchro to analyze freeways).

'''Note:''' The F1 key can be used to display a Description and Impact on Model Results for each data input field within HCS7.
<center>
====Table 905.3.5.2.1.1, HCS: Typical User-Adjusted Parameters (When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE"| Module!!style="background:#BEBEBE"| Input Section !!style="background:#BEBEBE"| Parameter(s)!!style="background:#BEBEBE"| Parameter Description!!style="background:#BEBEBE"|Suggested/Typical Value(s)
|-
|rowspan="6"| '''Streets (Signals)'''||Detailed Input Data||Queue Length Percentile||align="left"|This entry specifies the probability that a computed queue length will not be exceeded during any one signal cycle.||align="left"|Set the “Queue Length Percentile” to 95
|-
|rowspan="5"|Traffic||Arrival Type||align="left"|The quality of traffic progression as it approaches the intersection in question. Ranges from 1 to 6 with 1 = poor progression and 6 = exceptional progression||align="left"|'''Select Moderate Progression:''' 3 (HCS default)
|-
|Buses (#/hr)||rowspan="2" align="left"|Number of local buses/parking maneuvers that block traffic flow in a movement group within 250 ft. of the stop line (upstream or downstream). Non-zero bus stops/parking maneuvers per hour decreases the saturation flow rate.||align="left"|'''CBD Bus Stop:''' 12 buses/hr<br/>'''Non-CBD Bus Stop:''' 2 buses/hr
|-
|Parking (#/hr)||align="left"|Select side (L,R,or L+R) there is on-street parking and number of parking maneuvers per hour that occur adjacent to a movement group and within 250ft upstream of the stop line.
|-
|Heavy Vehicles (%)||align="left"|The percentage of trucks and buses for each traffic movement.||align="left"|Use field data or heavy vehicle estimates from the [https://www.modot.org/traffic-volume-maps MoDOT AADT Map]. Otherwise, use the HCM recommended default of 3%.
|-
|Speed Limit||align="left" colspan="2"|'''Typical Approach:''' Enter the speed limit or safe, legal speed anticipated at approach.<br/>'''Driveways:''' 25 mph
|-
|rowspan="2"|'''Freeways'''||Geometric Data||Freeway Free Flow Speed (FFS)||align="left" rowspan="2"|The speed of traffic at very low-flow conditions (when drivers are not constrained by other vehicles, roadway geometry, or traffic control).||align="left"|Use field data (85th percentile speed) if available. Otherwise, FFS can be estimated up to 5 mph above the speed limit.
|-
|Geometric Data||Ramp FFS||align="left"|'''Typical Ramps:''' 35 mph (HCS default for diverge/merge)<br/>'''Loop Ramps:''' 25 mph
|-
|rowspan="3"|'''Various Modules'''||Adjustment Factors||Driver Population||align="left" colspan="2"|The level of driver familiarity with the facility and is used to adjust the Speed and Capacity Adjustment Factors. Values range from all familiar (heavy commuter traffic) to all unfamiliar (heavy tourist traffic).
|-
|Geometric Data||Terrain Type/Grade||align="left" colspan="2"|'''Use field data to determine what grade is appropriate:'''<br/>'''Level:''' Any combination of vertical or horizontal alignment changes that do not affect heavy vehicle speeds in relation to passenger vehicles (grades ≤2%)<br/>'''Rolling:''' Any combination of vertical or horizontal alignment changes that affect heavy vehicle speeds in relation to passenger vehicles (grades 3-5%)<br/>'''Enter Specific Grade %:''' Use for extended segments that follow a constant incline/decline that affects heavy vehicle speeds in relation to passenger vehicles. If studying a segment that contains varying steep grade changes (≥6%), then individual analysis subsegments should be broken out by grade %.
|-
|Input/Demand Data||Peak Hour Factor (PHF)||align="left"|Peak hour traffic volumes are divided by the PHF to calculate the traffic flow rate during the busiest 15-minute period during the hour.||align="left"|'''Current Conditions:''' Use traffic data, if available, to calculate PHF.<br/>'''Current Conditions with no data and Future Conditions:''' Use default value of 0.92
|}
</center>

'''Streets Module (Signals)'''

An intersection’s traffic, phasing, and timing attributes are input into this module to calculate volume-to-capacity, delay, queuing, and other key MOE outputs using HCM 6 methodologies. Input data can be entered using a combination of “Classic Mode” input data boxes and “Visual Mode.”

Additionally, the module provides the ability to optimize a signalized intersection. For optimization, it is advised that the minimum cycle be set to 60 seconds, the maximum cycle be set to 190 seconds, the number of generations be set to 200 (HCS default), and that the mutation probability be set to 4%.

'''Stop Module (TWSC and AWSC)'''

These modules are ideal for analyzing isolated, stop control intersections by lane group and approach. For intersections closely spaced together with upstream signals, it is recommended that microsimulation models be used to account for the influences of queuing. The modules allow for no more than four approaches to be input and for no more than three lanes on an approach. Key attributes to be aware of for these modules include:
:• '''Percent Thrus Using Shared Lane:''' Can be input for an approach with more than one thru lane, though this is not typical to AWSC intersections and TWSC intersection minor approaches. A value of 50% should be used for rural major streets where drivers are less likely to pre-maneuver to the exclusive thru lane prior to the intersection. A value of 40% should be used in an urban setting where vehicles are familiar with the lane configuration.
:• '''Major Street Median Storage:''' The number of minor street vehicles that can refuge in the median during a two-stage crossing of the major street. Use one vehicle of storage space per 25ft of median. If undivided, this value is zero.
:• '''Short Left-Turn Pocket:''' Check box if no exclusive left turn lane is provided on the major street and it is possible for major street thru or right traffic to be delayed by left turning vehicles waiting for an acceptance gap. If left turn storage is available, enter the number of vehicles in Left-Turn Storage.

'''Roundabouts Module'''

Typically, MoDOT will analyze roundabouts using SIDRA software; however, the use of HCS may be considered for preliminary, coarse analysis. Note that this module is limited to one or two-lane entries, single bypass lanes, no more than two circulating lanes, and no more than four approaches.

'''Highways Module (Two-Lane and Multi-Lane)'''

HCS7 Highway analysis applies to uninterrupted flow segments of highway that are more than two miles from the nearest point of fixed operation. The highway analysis facility types are:
:1. Two-Lane – One lane in each direction, typically rural.
:2. Multi-Lane – Two to three lanes in each direction.

'''Freeways Module'''

HCS7 Freeway analysis is performed through segmentation due to the static, equation-based analysis limitations of HCM6. Segments are broken into the following facility types:
:1. Basic Freeway
:2. Merge/Diverge Ramp
:3. Weaving

Each freeway segment is established by boundaries, or influence areas. The Merge/Diverge ramps have an influence area length of 1,500 feet from the physical gore, while weaving segments have an influence area of up to 3,000 feet between each physical gore plus 500 feet upstream and downstream from each physical gore (see Fig. 905.3.5.2.1.2). Basic freeway segments typically fall in between the influence areas of merge/diverge or weaving segments. However, basic freeway segments can also have boundaries established by changes in traffic characteristics or geometrics such as changes in number of lanes, lane or shoulder width, grade percentage, terrain type, or posted speed.

[[image:905.3.5.2.1.2.jpg|center|800px|thumb|<center>'''Fig. 905.3.5.2.1.2, Freeway Ramp Influence Area Boundaries'''</center>]]

Merge/Diverge attributes to be aware of in the Freeway module include:
:• '''Number of Freeway Lanes:''' Enter the number of lanes in the travel direction of the freeway segment immediately before (upstream of) the merge or diverge influence area.
:• '''Freeway Length:''' Enter a value of 1500 ft., the typical distance for a freeway influence area.
:• '''Length of First Accel/Decel Lane (LA1, LD1):''' Enter the length of the first acceleration or deceleration lane. Lengths include the full taper length. See Fig. 905.3.5.2.1.3 and Fig. 905.3.5.2.1.4.
:• '''Length of Second Accel/Decel Lane (LA2, LD2):''' Enter the length of the second acceleration or deceleration lane. Lengths include the full taper length. See Fig. 905.3.5.2.1.3 and Fig. 905.3.5.2.1.4.
:• '''Upstream/Downstream Ramp:''' Select type of ramp (Merge or Diverge) that is upstream or downstream of the ramp influence area.
:• '''Distance to Upstream/Downstream Ramp:''' Enter the distance to the adjacent ramp, measured between the points at which the left edge of the leftmost ramp lane meets the right-lane edge of the freeway. The maximum distance that HCS allows between adjacent ramps is 99,999 feet (approximately 19 miles), which is an arbitrary allowance of distance, given that merge/diverge ramps have an influence area of 1,500 feet from the physical gore.

[[image:905.3.5.2.1.3.jpg|center|700px|thumb|<center>'''Figure 905.3.5.2.1.3, Merge Ramp Acceleration Lanes'''</center>]]

[[image:905.3.5.2.1.4.jpg|center|700px|thumb|<center>'''Figure 905.3.5.2.1.4, Diverge Ramp Deceleration Lanes'''</center>]]

Weaving attributes to be aware of in the Freeway module include:
:• '''Weaving Configuration:''' Select One-Sided or Two-Sided. See Figure 905.3.5.2.1.5.
[[image:905.3.5.2.1.5.jpg|center|700px|thumb|<center>'''Figure 905.3.5.2.1.5, Weaving Segment Configuration'''</center>]]

:• '''Number of Maneuver Lanes:''' Enter the number of lanes from which weaving maneuvers may be made with either one or no lane changes. This value will range from 2-3 for One-Sided and will always be 0 for Two-Sided.
:• '''Short Length (LS):''' Enter the distance between the end points of any barrier markings that prohibit or discourage lane changing. See Figure 905.3.5.2.1.6.
[[image:905.3.5.2.1.6.jpg|center|500px|thumb|<center>'''Figure 905.3.5.2.1.6, Weaving Segment Lengths'''</center>]]

:• '''Interchange Density:''' Enter the average number of interchanges 3 miles upstream and 3 miles downstream of the middle of the weaving segment.
:• '''Terrain Type:''' Select Level, Rolling, or Enter Specific Grade %. Refer to Basic Freeway Segment analysis for guidance on Terrain Type.
:• '''Minimum FR Lane Changes:''' Minimum number of lane changes that a vehicle must make to complete a Freeway to Ramp movement. See Figure 905.3.5.2.1.5.
:• '''Minimum RF Lane Changes:''' Minimum number of lane changes that a vehicle must make to complete a Ramp to Freeway movement. See Figure 905.3.5.2.1.5.
:• '''Minimum RR Lane Changes:''' Minimum number of lane changes that a vehicle must make to complete a Ramp to Ramp movement. This only applies to a Two-Sided configuration. See Figure 905.3.5.2.1.5.
:• '''Weaving Demand Data Inputs:'''
[[image:905.3.5.2.1.7.jpg|center|450px|thumb|<center>'''Figure 905.3.5.2.1.7, Weaving Segment Volumes'''</center>]]
::i. Freeway-to-Freeway – See '''V<sub>FF</sub>''' in Figure 905.3.5.2.1.7.
::::1. Enter the Demand (Traffic Volumes).
::::2. Demand Adjustment Factor – Use default value of 1.0.
::::3. PHF – Use mainline PHF.
::::4. Total Trucks % – Use mainline Heavy Vehicle %.
::ii. Ramp-to-Freeway – See '''V<sub>RF</sub>''' in Figure 905.3.5.2.1.7.
::::1. Enter the Demand (Traffic Volumes)
::::2. Demand Adjustment Factor – Use default value of 1.0.
::::3. PHF – Use mainline PHF.
::::4. Total Trucks % – Use mainline Heavy Vehicle %.
::iii. Ramp-to-Ramp – See '''V<sub>RR</sub>''' in Figure 905.3.5.2.1.7.
::::1. Enter the Demand (Traffic Volumes)
::::2. Demand Adjustment Factor – Use default value of 1.0.
::::3. PHF – Use mainline PHF.
::::4. Total Trucks % - Use mainline Heavy Vehicle %.
::iv. Freeway-to-Ramp – See '''V<sub>FR</sub>''' in Figure 905.3.5.2.1.7.
::::1. Enter the Demand (Traffic Volumes)
::::2. Demand Adjustment Factor – Use default value of 1.0.
::::3. PHF – Use mainline PHF.
::::4. Total Trucks % – Use mainline Heavy Vehicle %.

:'''Note:''' If weaving movement demand volumes are unknown, take the ramp with the lower volume and apply the proportion of the upstream or downstream ramp and mainline volumes to determine the '''V<sub>RF</sub>/V<sub>RR</sub>''' or '''V<sub>FR</sub>/V<sub>RR</sub>''' volume splits. Once the volume split is determined, the remaining movement volumes can be determined through volume balancing.

'''Freeway (Facility) Module'''

The HCS7 Freeways Facility module is recommended when studying a freeway corridor. It analyzes a freeway facility by linking the analysis segments of Basic Freeway, Merge/Diverge, and Weaving into a single interface. Jam density and queue discharge values are applied to the string of analysis segments to determine potential bottleneck locations and adjust the capacity of adjacent upstream analysis segments to simulate the effects of queuing. Due to the static limitations of HCS7, it is not recommended to analyze oversaturated scenarios along freeway facilities with dynamic queuing interactions, but it is a good way to look at an undersaturated freeway corridor over multiple time intervals.

When starting a Facility analysis, the General tab contains basic information and the ability to apply certain parameters globally to the facility.

The Segments tab is where the facility is segmented into the traditional basic, merge/diverge, and weave freeway segments. The overlap segment also is introduced in the Facility module (refer to Figure 905.3.5.2.1.8 for an example). An overlap segment is used when the following three criteria are met:
:1. A merge segment is followed by a diverge segment,
:2. The ramp gores are between 1500 ft. and 3000 ft. apart, and
:3. There is no continuous auxiliary lane between the ramps, which would classify it as a weave.
[[image:905.3.5.2.1.8.jpg|center|475px|thumb|<center>'''Figure 905.3.5.2.1.8, Overlap Segment Example'''</center>]]

In these cases, the overlap segment is treated similarly to a basic segment, but the length is defined as 3000 ft. minus the distance between the ramp gores. The facility can be automatically segmented by using the segmentation button at the top of the window. This allows the user to enter basic information like the presence of on- and off-ramps, the distances between them, and the number of lanes. The information is then used to automatically segment the facility into basic, merge/diverge, weave, and overlap segments.

The details tab is where the typical input parameters for each freeway segment are entered.

The results tab shows the typical outputs for each freeway segment.

The report tab displays the analysis results with options to show a segment or facility report or a heat map of the results for various measures of effectiveness.

Facility by segmentation starts a new Facility analysis through automatic segmentation, as described above.

Facility Planning is based off HCM Chapter 25 Section 6 and has fewer data requirements than the Facility module. It is intended for a higher-level analysis.

'''Special Cases of Freeway Segmentation'''

There are a variety of unique, special cases that can occur in the analysis of freeway segments. As a general rule of thumb, it is always best to review the HCM to see if the unique situation is directly addressed, and if not, to subdivide the segment of concern into multiple segments to analyze. Special cases that can occur often include, but are not limited to the following list:

:• '''Weaving Segments that exceed the weaving maximum length:''' The weaving maximum length (LMAX) is the length at which weaving turbulence no longer has an impact on the capacity of the weaving segment. The HCM 6 provides Equation 13-4 for calculating LMAX and Exhibit 13-11 (Table 16 below) with estimated LMAX values. When the segment length (LS) is less than LMAX, the HCS weaving module is appropriate to calculate segment capacity. However, when LS is greater than or equal to LMAX, the merge and diverge junctions should be treated separately with ramp capacity checks for those segments. Additionally, any distance falling outside the influence area of the merge and diverge segments would be considered a basic freeway segment and analyzed accordingly.

:<u>HCM Equation 13-4</u>
:::::L<sub>MAX</sub> = [5,728 (1 + VR)<sup>1.6</sup>] – [1,566 N<sub>WL</sub>] 
:where
::Lz,sub>MAX</sub> = Maximum weaving segment length (in feet, using the short length definition)
::VR = volume ratio (weaving demand flow rate / total demand flow rate)
::N<sub>WL</sub> = # of lanes from which weaving maneuvers may be made with either one or no lane changes
::L<sub>S</sub> = Length of the segment

:If L<sub>S</sub> < L<sub>MAX</sub>, then Determine the Weaving Segment Capacity; OR
:If L<sub>S</sub> ≥ L<sub>MAX</sub>, analyze the merge and diverge junctions as separate segments by using HCM 6 methodology in Chapter 14
<center>

====Table 905.3.5.2.1.9, Variation of Weaving Length====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" rowspan="2"| VR!!style="background:#BEBEBE" colspan="2"| Maximum Weaving Length (ft)
|-
!style="background:#BEBEBE"| N<sub>WL</sub> = 2!!style="background:#BEBEBE"| N<sub>WL</sub> = 3
|-
|0.1||3,540||1,974
|-
|0.2||4,536||2,970
|-
|0.3||5,584||4,018
|-
|0.4||6,681||5,115
|-
|0.5||7,826||6,260
|-
|0.6||9,019||7,453
|-
|0.7||10,256||8,690
|-
|0.8||11,538||9,972
|}
</center>

:• '''Acceleration/Deceleration Lanes Longer than 1,500 feet:''' HCS allows only merge and diverge lanes to be entered that range from 0 feet to 1,500 feet. Ramp lanes that are shorter than 1,500 feet are not an issue for HCS analysis. However, for lanes that are longer than 1,500 feet, it is advised that the merge/diverge segment be broken up into multiple segment types for analysis. For instance, a diverge lane that is longer than 1,500 feet should be subdivided into a diverge segment of 1,500 feet and then another diverge segment with a continuous lane drop (analyzed as a basic freeway segment). Also, certain merge/diverge segments can be can analyzed with a continuous lane add or lane drop because those segments are eventually analyzed operationally as a basic freeway segment, per methodology from Chapter 12 of the HCM 6.
:• '''Back-to-back merge or diverge segments less than 1,500 feet apart:''' Use the HCS Facility module to analyze back-to-back merge and/or diverge segments. In these situations, certain merge/diverge segments can be analyzed as merge/diverge segments with a freeway length of less than 1,500 feet.
:• '''Taper Exit Only:''' A taper only exit would be analyzed in the diverge module using the same approach and methodologies as a typical diverge segment, but with a deceleration lane length of zero. The “taper only” exit would not impact the calculations.

'''Travel Time Reliability in HCS'''

FHWA defines travel time reliability as “the consistency or dependability in travel times, as measured from day-to-day and/or across different times of the day.” Conventional capacity analysis methods evaluate average weekday peak period traffic operations. Generally, commuters do not experience "average" travel conditions on any given day, rather they experience a range of travel times. Only the longest commutes are remembered because travelers must base their plans on them to ensure on-time arrival. Improving travel time consistency can improve user perspective of operations even if the average travel time does not decrease. A paradigm shift from capacity addition to capacity efficiency is occurring as congestion continues to grow amid limited resources to add capacity.

Travel time reliability (TTR) analysis focuses on the influence factors on the variability of travel times, demand fluctuations, weather events, incidents, work zones, and special demand events. The only variable in density/delay-based analyses is demand, however, travel times can fluctuate even on a facility with consistent weekday peak period demand levels. Analytical methods of TTR use existing data sources to evaluate facility reliability based on historical data. Predictive methods use variable distributions calculated from historical data to predict the future reliability of a facility.

For the first time, the HCM (6<sup>th</sup> Edition) includes a predictive method to evaluate TTR. Dedicated chapters for both freeway reliability and urban street reliability, Chapters 11 and 17 respectively, provide a methodology to implement predictive TTR analysis as an extension of existing freeway facility and signalized corridor analysis methodology. HCS7 implemented the new methods via new modules, Freeway Reliability and Streets Reliability, that use Freeway Facility and Streets as a base model to be analyzed for reliability.

'''Predictive Reliability Analysis Fundamentals'''

HCS7 generates at least one 24-hour scenario for every month/day-of-week combination. Influencing events are applied to each scenario to generate a sample of travel times over a specified period (typically one year). Work zones and special demand events are applied to the scenarios deterministically; an event is recorded for each time/segment combination that falls within the scheduled start and end times. Weather and incident events occur with some randomness and thus treated as a stochastic variable. These events are assigned to scenarios based on default event distributions applied directly or modified by the analyst to reflect local data.

Speed, demand, and capacity adjustment factors are used to adjust the predicted travel time of each scenario to account for occurrence of influencing factor events. Once scenario travel times have been adjusted, the output of the HCS7 reliability modules are derived from the cumulative density function (CDF) of scenario travel times and travel time probability distribution function (PDF) plots. Figure 905.3.5.2.1.10 is a simple flow chart of the reliability methodology.
[[image:905.3.5.2.1.10.jpg|center|800px|thumb|<center>'''Figure 905.3.5.2.1.10, High-Level HCM Predictive Method Flow Chart'''</center>]]

'''Freeway Reliability'''

Deterministic analysis of a sequence of HCM segments (basic, diverge, merge, and weaving) as an entire freeway facility was introduced in HCM 2010 and expanded in HCM 6<sup>th</sup> edition. The HCS7 Freeway Reliability module inherits facility analysis parameters from the Freeway Facilities file on which it is based. Segment data (type, length (ft), number of lanes, free-flow speed, terrain, etc.), base demand data (single day demand data used in the facilities analysis), and analysis parameters (start/end time, urban/rural, etc.) can only be modified in the underlying Facilities file and reimported into the Freeway Reliability module.

'''Freeway Reliability Analysis Parameters'''

After a base freeway facilities file is either loaded or created, the analyst completes general information fields not already imported from the Facility file (analyst, agency, analysis year, etc.). The reporting period refers to the range of dates included in the TTR analysis. An additional section allows the analyst to select which days of the week (DOW) are included in the reporting period. The influencing variables used in the analysis can be modified by the analyst to tailor the study to the project. Individual demand scenarios (month/DOW combination) can be repeated several times to increase the sample size of stochastic influencing events. The HCS7 default is four.

'''Weather Events'''

Adverse weather events may negatively affect travel times directly by forcing drivers to reduce their speed and/or indirectly by increasing incidents. HCS7 considers rain (medium or heavy), snow (light-medium, medium heavy, or heavy), severe cold, visibility (low, very low, and minimal), and non-severe weather. A nationwide default monthly weather event distribution is built-in to HCS7 as are monthly weather event distributions for approximately 100 cities in the US. Table 905.3.5.2.1.11 shows a list of regions within or near Missouri with built-in weather event data. Default capacity and speed adjustment factors for various freeway speed limits can be adjusted by the analyst if warranted by local or regional conditions. 

{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center" align="right" margin-left:12px
|+ Table 905.3.5.2.1.11,<br/>Regions with Pre-loaded Weather Event Data Within or Near Missouri
! style="background:#BEBEBE" |Regional Weather Regions
|-
|Kansas City, MO 
|-
|St. Louis, MO 
|-
|Tulsa, OK 
|-
|Omaha, NE 
|-
|Memphis, TN
|-
|Des Moines, IA
|}

'''Demand Data Parameters'''

HCS7 provides default freeway demand ratios for each month/DOW combination to adjust for demand variation over the course of the reporting period for both urban and rural freeways. These default ratios are automatically adjusted to become relative to the date for which demand in the base Freeway Facilities file applies. The analyst can also update the default demand ratio if more specific data exists.

'''Incident Data Parameters'''

Within the TTR context, incidents are events along the roadway that impact the rest of the traffic stream. Examples include crashes, disabled vehicles, emergency work zones, fallen trees, etc. that are common, but the exact time/place is unpredictable. Incidents reported to the closest Traffic Management Center are a common source for this data because they are generally only reported if there is an impact to traffic flow.

HCS7 provides three possible input methods: local incident frequency, local crash frequency, and calculated crash frequency. If sufficient incident data is available a frequency/rate can be calculated and directly input into the module. If incident data is unavailable but crash data is available, crash data and an incident-to-crash ratio (ICR) can be used to indirectly calculate the incident frequency. In the event no data is available, or the facility being analyzed is proposed new construction, the Highway Economic Requirements System (HERS) crash rate model can be used with an ICR to estimate the incident frequency per 100 million VMT. The default ICR is 4.9.

'''Work Zone Data Parameters'''

Known work zones, either past or future, can be explicitly added to the reliability analysis by providing the start/end date, start/end time each day, type of lane closure, area type (urban/rural), day/night, and speed limit. Each event has a default capacity reduction populated (13.7% for freeway work zones) that can be modified by the analyst if warranted. Additionally, [[616.25 MoDOT Work Zone Guidelines|EPG 616.25 MoDOT Work Zone Guidelines]] includes anticipated work zone capacity reductions.

'''Special Events Parameters and Capabilities'''

The special event component of the reliability methodology is primarily used to exclude from the TTR analysis day/time periods impacted by an abnormal event such as a sporting event, concert, fair, or other high capacity venue with projected traffic far in excess of normal peak period conditions. The traffic demand generated by such events should overwhelm the adjacent roadway network such that operations bear no resemblance to typical peak periods. To include these observations in the distribution of travel times may compromise the conclusions produced by the methodology.

If the analysis will include special events, HCS7 also has the capability to import a different facilities file for use during the duration of the event. This could be used to reflect modified traffic patterns, especially for longer events such as festivals and fairs that limit the ability of commuters to adjust their travel plans. In the event of a major work zone, this tool could also be used to implement temporary work zone traffic control measures while the work zone is active.

'''Urban Streets Reliability'''

HCS7 includes a dedicated module to implement the urban streets reliability methodology included in the 6<sup>th</sup> edition of the HCM. The Urban Streets methodology in the HCM analyzes signalized arterial corridors with multiple signalized intersections. Many of the TTR concepts presented in the freeway reliability methodology are applied to the street’s methodology, however there are some parameters unique to the street’s reliability methodology.

After a base streets file is uploaded into the reliability module, the analysis page is structured like its freeway reliability counterpart. The start and end date of the reporting period are specified, and the days of the week are selected. The number of study days during each month, study period start and end times, and the number of scenarios are tabulated and displayed automatically.

'''Urban Streets Weather Data'''

Like the freeway reliability methodology, weather data for many US cities is preloaded into the reliability. In addition to the relevant cities listed in Table 905.3.5.2.1.11, the Missouri cities of Columbia and Springfield are included in the Streets Reliability module in HCS7.

{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center" align="right" margin-left:10px
|+ Table 905.3.5.2.1.12,<br/>Weather Data Points for HCS7 Streets Reliability Module
! style="background:#BEBEBE" |Weather Data Metric!!style="background:#BEBEBE" | Units
|-
|Total normal precipitation||Inches
|-
|Total normal snowfall||Inches
|-
|Days with precipitation||Days
|-
|Daily mean temperature||°F
|-
|Precipitation rate||In/hr
|}

The weather metrics utilized for the Streets methodology are different than the freeway reliability module. In addition to the weather data points, the streets reliability module includes a parameter to account for the length of pavement runoff after a snow event and demand factors for dry weather, rain events, and snow events.

'''Urban Street Demand Ratios'''

HCS7 Streets provides three possible functional classes: expressway, principal arterial, and minor arterial. Default hourly demand ratios are provided for weekdays and weekends. Like the Freeway Reliability module, day of week and monthly demand adjustments are provided as is the base demand ratio for the date on which the base streets file was analyzed. Local data can be used if available for all demand ratios.

'''Urban Street Incident Data'''

Streets Reliability incident data differs the most from the Freeway Reliability module among the input components. An annual average crash frequency is specified for all intersections and segments comprising the Streets network. Default crash frequency adjustment factors are provided for different weather events (rain, wet pavement, snow, ice, etc.). Incident detection time and the response time for different weather events are pre-populated with default values but can be adjusted for a specific facility or application.

A table of default clearance times is based on the street location (segment or intersection), event type (crash or non-crash), lane location, and severity (injury or non-injury for crashes, breakdown or other for non-crash events) for various weather conditions (dry, rain, wet pavement, or snow/ice). Another table provides a default distribution for all the combinations included in the clearance timetable and proportions for each category individually.

'''Urban Street Scenario Generation'''

Scenario generation parameters are set at the end of the procedure in the Streets Reliability module. The analyst can select to include weather, demand, and incidents in the reliability analysis. All three variables are stochastic so a random seed can be defined for each variable. The analyst can also select to randomize the demand volume for each analysis period. The number of replications of each scenario is also specified at this point.

'''Travel Time Reliability Measures of Effectiveness'''

Unlike traditional density or delay based MOEs that use a LOS scale, TTR utilizes a set of measures to tailor output to the specific analysis. Changes in travel times resulting from operational-level improvements are best reflected by 80th percentile travel times. The 95th percentile travel time is commonly referred to as the planning time, the time most commuters allow to achieve an acceptable on-time arrival rate. Graphical plots of the travel time distribution can also provide a visual indicator and comparison of TTR.

Most TTR metrics are based on the Travel Time Index (TTI), the scenario travel time divided by the base free-flow travel time. TTI is preferred over the actual travel times because it allows for comparisons between facilities of different lengths. HCS7 reports percentiles in TTI along with the base free-flow travel time imported from the base Sheets file. Table 905.3.5.2.1.13 lists several TTR metrics reported in the TTR modules of HCS7.

<center>

====Table 905.3.5.2.1.13, Common Travel Time Reliability Metrics ====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" |Reliability Metric !!style="background:#BEBEBE"| Description
|-
|width="300"|Base free-flow travel time (seconds)||width="400" align="left"|Corridor travel time at free-flow speed, used as the denominator of the TTI calculation.
|-
|Mean TTI|| align="left"|Average TT/base free-flow TT; usually close to the 50<sup>th</sup> percentile TTI unless very high TT outliers are included in the data.
|-
|80<sup>th</sup> Percentile TTI|| align="left"|80<sup>th</sup> percentile TT/base free-flow TT; best measure of operational improvements
|-
|Planning Time Index (PTI)|| align="left"|95<sup>th</sup> percentile TT/base free-flow TT; time allotted to achieve an acceptable on-time arrival rate, typically for work or appointment.
|-
|Reliability Rating (%)|| align="left"|Percentile of scenarios with a TTI < 2.5; 2.5 is a common reliability threshold.
|-
|Total Delay (veh-hr)|| align="left"|Allows for overall performance comparison between different facilities or different operational strategies.
|}
</center>

===905.3.5.2.2 SIDRA===

The ''Signalized and Unsignalized Intersection Design and Research Aid'' (SIDRA) software is a deterministic tool that can be used to analyze roundabout operations, signalized and unsignalized intersections, single-point urban interchanges, and signalized midblock crossings for pedestrians. In the United States, SIDRA is primarily used to analyze roundabout operations because of its ability to model the effects of gap-acceptance (including roundabout geometry) on roundabout Level of Service (LOS). The software references here are to SIDRA 8.

MoDOT recommends SIDRA as a tool for analyzing roundabout operations.

SIDRA software uses two roundabout capacity models: the US HCM model and the SIDRA Standard model. These two models are summarized below:
:1. '''US HCM 6 Roundabout Capacity Model''' – Based on the calibration of most model parameters using HCM, 6<sup>th</sup> Edition, default values as applicable
:2. '''SIDRA Standard Roundabout Capacity Model''' – Based off the HCM, but provides additional, detailed analysis for the following:
::a. The effect of roundabout geometry parameters (roundabout size, circulating road width, entry radius, and angle, etc.) on capacity
::b. Critical gap and follow-up headway reduction with increasing demand flows in its design life analysis
::c. The effects of vehicle arrivals based on adjacent traffic control devices.

Therefore, MoDOT recommends that the “SIDRA Standard Roundabout Capacity Model” be the capacity model used for analysis in SIDRA. The HCM 6 Capacity Model is also available for additional analysis if desired. The ability to select the capacity model is available in the “Roundabouts” dialog box in SIDRA. For roundabouts near or over capacity, consider using VISSIM as an additional check.

'''Model Development'''

Table 905.3.5.2.2.1 summarizes key parameters with specific MoDOT guidance for proper application. The table includes the SIDRA parameter, the dialog box the parameter is in, the parameter description, and the MoDOT suggested default value. Additionally, [[#Fig. 905.3.5.2.2.2|Fig. 905.3.5.2.2.2]], [[#Table 905.3.5.2.2.3, General Roundabout Design & Operational Elements|Table 905.3.5.2.2.3 and Table 905.3.5.2.2.4]] provide more detailed information on parameters relating to roundabout geometry measurements, general roundabout design and operational elements, and extra bunching percentages, respectively.

There are additional SIDRA input parameters not included in EPG 905.3.5.2.2 because they are predominantly user-defined values based on existing conditions, recent traffic count data, or project design plans. For a detailed introduction to SIDRA and how to enter all parameters, it is recommended that the user access the SIDRA User Guide using “File\User Guide, Glossary, & Help” in the SIDRA interface.

<center>
====Table 905.3.5.2.2.1, SIDRA Lane Geometry: Typical User-Adjusted Parameters<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE" |Dialog Box !!style="background:#BEBEBE"| Parameter(s)!!style="background:#BEBEBE"| Parameter Description!!style="background:#BEBEBE"| Suggested/Typical Value(s)
|-
|align="center"|'''Settings'''||Current Setup||align="left" colspan="2"|“US HCM (customary)” should be selected in the Settings tab of the ribbon at top of the SIDRA interface before a roundabout is created.
|-
|align="center"|'''Roundabouts'''<br/>(“Options” Tab)||Roundabout Capacity Model,<br/>Roundabout LOS Method,<br/>Delay Model<br/>Refer to Figure 905.3.5.2.2.1, to the right, for a dialog box graphic.||align="left" colspan="2"|'''Roundabout Capacity Model:''' Select the “SIDRA Standard” model.<br/>'''Roundabout LOS Method:''' Select the “Same as Sign Control” option. '''Note:''' For roundabouts, it is important to assess other MOEs in addition to LOS. Common MOEs for roundabouts include v/c ratios, LOS (based on delay), and queuing.<br/>'''Delay Model:''' Uncheck both “HCM Delay Formula” and “Exclude Geometric Delay.”<br/>'''Additional Information:''' The “HCM Delay Formula” checkbox influences if back of queue or cycle average queue lengths will be calculated/displayed using HCM equations.<br/>Geometric delay is the delay caused by vehicles slowing down when entering, negotiating, and exiting the roundabout. Since the HCM roundabout LOS delay does not consider geometric delay (it calculates delay solely based on unsignalized intersection control delay), the “Exclude Geometric Delay” checkbox is automatically checked whenever “HCM Delay Formula” is checked. Therefore, it is helpful to ensure that geometric delay is considered when comparing the operations of different intersection alternatives with different geometric designs.<br/>[[image:905.3.5.2.2.1 exhibit.jpg|875px|thumb|center|'''<center>Figure 905.3.5.2.2.1, Roundabout LOS Method'''</center>]]
|-
|rowspan="7" align="center"|'''Roundabouts'''<br/>(“Roundabout<br/>Data” Tab)||Number of Circulating Lanes||The number of lanes circulating around the roundabout||User-defined values from field data and design plans.
|-
|Circulating Width||The total width of all lane(s) as it circulates the roundabout.||'''Single-Lane Roundabout:''' 20 feet (SIDRA default)<br/>(NCHRP 672 single-lane acceptable range: 16 to 20 feet)<br/>'''Multi-Lane Roundabout:''' 15 feet per lane<br/>(NCHRP 672 acceptable range: 14 to 16 feet per lane)
|-
|Inscribed Diameter||Refer to [[#Fig. 905.3.5.2.2.2|Fig. 905.3.5.2.2.2]]||User-defined values from field data and design plans. Refer to [[#Table 905.3.5.2.2.3, General Roundabout Design & Operational Elements|Table 905.3.5.2.2.3]] for typical ranges for roundabout types.
|-
|Island Diameter||The diameter of the center island. See [[#Fig. 905.3.5.2.2.2|Fig. 905.3.5.2.2.2]] for an illustration.||The island diameter is dependent on the inscribed diameter and circulating width of the roundabout. Use the following equation to calculate the island diameter:<br/>Island Diameter = (Inscribed Diameter) – 2 x (Circulating Width)
|-
|Environment Factor<sup>'''1'''</sup>||Using this factor, you can calibrate the SIDRA Standard capacity model to allow for less restricted (higher) capacity and more restricted (lower) capacity. This parameter is only applicable/displayed for the “SIDRA Standard Capacity Model.”<br/>The Environment Factor allows for the effect of different driver behavior (driver aggressiveness and alertness affecting driver response times) and general characteristics of the roundabout environment in terms of roundabout design type, visibility, significant grades, operating speeds, size of light and heavy vehicles, etc.<br/>Values range from 0.5 to 2.0.||'''Single-Lane Roundabout:'''<br/>Use 1.1 where drivers are generally familiar with roundabouts (e.g., at least one other roundabout is already in use in the general vicinity).<br/>Use 1.2 for anywhere else.<br/>'''Two-Lane Roundabout:'''<br/>Use 1.2<br/>'''Additional Notes:'''<br/>MoDOT advises that no environment factors less than 1.0 should be used. Typically, a range of 1.1 to 1.2 should be used. Future years could use 1.1 assuming more familiarity in future.<br/>“Model Calibration Factors” are the parameters corresponding to the Environment Factors and are only applicable when the HCM capacity model is used.
|-
|Entry Radius||The ''minimum radius of curvature'' of the outside curb line at entry||'''Single-Lane Roundabout:''' 65 feet (SIDRA default)<br/>(NCHRP 672 single-lane acceptable range: 50 to 100 feet)<br/>'''Two-Lane Roundabout:''' 100 feet (NCHRP 672 acceptable range)
|-
|Entry Angle||The ''angle of conflict between the entering and circulating streams''||'''SIDRA Default Value:''' 30 degrees<br/>(NCHRP 672 acceptable range: 20 degrees to 40 degrees.)
|-
|align="center" rowspan="2"|'''Intersection'''||Site Data, Approach Geometry, & Approach Data||colspan="2"|Dialog box to input intersection and road names to determine number of intersection legs (can add up to 8 legs), input each approaching link’s distance, and input if legs allow one-way or two-way traffic.
|-
|Extra Bunching||The effect of upstream signals on gap-acceptance capacity of roundabouts by increasing the bunching.<br/>The distance to the upstream signal should be measured from the downstream side of the traffic signal to the stop bar of the roundabout approach.||'''If no traffic signal on approach that is within 2,600 feet:''' 0%<br/>'''Otherwise:'''<br/>Refer to [[#Table 905.3.5.2.2.4, Extra Bunching Percentages|Table 905.3.5.2.2.4]]
|-
|align="center"|'''Lane Geometry'''||Lane Type||colspan="2"|<u>Parameter setting to determine if entry lanes are “normal” entry lanes or slip/bypass lanes with either short angles or high angles.</u><sup>'''2'''</sup>
|-
|align="center" rowspan="2"|'''Pedestrians'''||Pedestrian Movement Definition||colspan="2"|If including pedestrian data as part of analysis, select “Staged Crossing” as the “Main Crossing” type. Enter data separately for both stages of the crossing.
|-
|Pedestrian Walking Speed||colspan="2"|Set the pedestrian walking speed to 3.5 feet/second (per the HCM).
|-
|align="center" rowspan="2"|'''Volumes'''||Heavy Vehicle Percentages||SIDRA defines this as any vehicle with more than two axles or with dual tires on the rear axle.||Use traffic count data
|-
|Peak Flow Factor||The equivalent of the Peak Hour Factor when the timeframe is equal to one hour.||'''SIDRA Default Value:''' 0.92
|-
|align="center"|'''Vehicle Movement Data'''||Approach Cruise Speed/Exit Cruise Speed||The average uninterrupted travel speed (i.e., the speed of a vehicle without the effect of delay at the intersection).||If available, use speed data of vehicles, as collected in the field. Otherwise use the posted speed limit.
|-
|align="center" rowspan="2"|'''Parameter Settings'''||Site Level of Service Method (in “Options” tab)||colspan="2"|Set to “Delay & Degree of Saturation (SIDRA)”
|-
|Delay and Queue (in “Model Parameters” tab)||colspan="2"|Uncheck the “Exclude Geometry Delay” and “HCM Formula Delay” checkboxes
|-
|colspan="4" align="left"|<sup>'''1'''</sup> Environment factors of 1.1 and 1.2 (for both current and future conditions) are conservative estimates of driver behavior. SIDRA provides hypothetical comparisons between 1.2 and 1.1 environment factors to show the impacts of a 0.1 environment factor change on capacity and driver response time. Refer to SIDRA User Guide.
|-
|colspan="4" align="left"|<sup>'''2'''</sup> The impacts to traffic on the overall roundabout from the slip/bypass lane may not be fully reflected in the SIDRA outputs. It is advised that the user be cognizant of this if slip/bypass lane volumes are high. Different roundabout geometric options or analysis tools (such as VISSIM) should be considered.
|}

<div id="Fig. 905.3.5.2.2.2"></div>
[[image:905.3.5.2.2.2.jpg|center|550px|thumb|'''<center>Fig. 905.3.5.2.2.2, Roundabout Geometry'''</center>]]
<center>'''Note:''' Exhibit based on SIDRA 8 User’s Guide</center>

====Table 905.3.5.2.2.3, General Roundabout Design & Operational Elements====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" |Design Element!!style="background:#BEBEBE"| Mini-Roundabout !!style="background:#BEBEBE"| Single-Lane Roundabout!!style="background:#BEBEBE"| Multi-Lane Roundabout
|-
|align="left"|'''Desirable maximum entry design speed'''||15 to 20 mph||20 to 25 mph||25 to 30 mph
|-
|align="left"|'''Maximum number of entering lanes per approach'''||1||1||2+
|-
|align="left"|'''Typical inscribed circle diameter'''||45 to 90 feet||90 to 180 feet||150 to 300 feet
|-
|align="left"|'''Central island treatment'''||Fully traversable||Raised (may have traversable apron)||Raised (may have traversable apron)
|-
|align="left"|'''Typical daily service volumes on four-leg roundabout (vehicles/day)<sup>1,2'''</sup>||Up to 15,000||Up to 25,000||Up to approximately 45,000 for two-lane roundabout
|-
|align="left" colspan="4" width=800|Note: table based on Exhibit 1-9 from the NCHRP 672
|-
|align="left" colspan="4" width="800"|<sup>'''1'''</sup> Traffic volumes are total daily volumes of all legs that are entering the roundabout. Operational analysis needed to verify upper limit for specific applications or for roundabouts with more than two lanes or four legs.
|-
|colspan="4" align="left"|<sup>'''2'''</sup>For additional clarity on when different roundabout types are appropriate, refer to Figure 905.3.5.2.2.5 and/or [[#Table 905.3.5.2.2.4, Hourly Volume Thresholds for Estimating the Number of Entry Lanes Required|Table 905.3.5.2.2.6]].
|}

====Table 905.3.5.2.2.4, Extra Bunching Percentages====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
! style="background:#BEBEBE" |Distance to<br/>Upstream Signal (feet)!!style="background:#BEBEBE"| < 350 ft.!!style="background:#BEBEBE"| 350 ft. – 700 ft.!!style="background:#BEBEBE"| 700 ft. – 1,300 ft.!!style="background:#BEBEBE"|1,300 ft. – 2,000 ft. !!style="background:#BEBEBE"|2,000 ft. – 2,600 ft.!!style="background:#BEBEBE"| >2,600 ft.
|-
|'''Extra Bunching (%)'''||25||20||15||10||5||0
|-
|colspan="7" align="left"|Note: table based on SIDRA 8 User’s Guide.
|}


[[image:905.3.5.2.2.5.jpg|center|850px|thumb|'''<center>Fig. 905.3.5.2.2.5, Maximum Daily Service Volumes for a Four-Leg Roundabout'''</center><br/>'''Note:''' Exhibit 3-1 from the FHWA’s ''Roundabouts: An Informational Guide''.<br/>Displayed AADT are total roundabout entering volumes. For a three-leg roundabout, use 75% of the maximum AADT volumes shown.]]


====Table 905.3.5.2.2.6, Hourly Volume Thresholds for Estimating the Number of Entry Lanes Required====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE" |Volume Range<br/>(Vehicles per Hour, vph)<sup>1</sup>!!style="background:#BEBEBE"|Estimated Number of Lanes
|-
|align="center"|'''0 to 1,000 vph'''||Single-lane entry likely to be sufficient.
|-
|align="center"|'''1,000 to 1,300 vph'''||• Two-lane entry may be needed.<br/>• Single-lane entry may be sufficient based upon more detailed analysis.
|-
|align="center"|'''1,300 to 1,800 vph'''||Two-lane entry likely to be sufficient.
|-
|align="center"|'''Above 1,800 vph||• More than two entering lanes may be required.<br/>• A more detailed capacity evaluation should be conducted to verify lane numbers and arrangements.
|-
|width="750" colspan="2"|'''Note:''' table based on Exhibit 3-14 from the NCHRP 672.<br/><sup>'''1'''</sup> Traffic volumes displayed are the sum of the entering (ve) and circulating/conflicting (vc) volumes for each, individual approach at a roundabout. Refer to Figure 905.3.5.2.2.7.
|}

[[image:905.3.5.2.2.7.jpg|center|650px|thumb|'''<center>Fig. 905.3.5.2.2.7, Traffic Flows at a Roundabout Entry'''<br/>'''Note:''' Based on Exhibit 3-13 from the NCHRP 672.</center>]]

</center>
'''SIDRA Calibration'''

SIDRA provides the following parameters for the calibration of the roundabout capacity model. These parameters affect the follow-up headway and critical gap values (and subsequently, capacity) of all lanes on the selected leg of a roundabout. Note that the SIDRA default value should generally be used for these parameters unless calibrating the SIDRA model to field data.
:• '''Roundabout Model Calibration Factor (HCM methodology)/Environmental Factor (SIDRA methodology):''' Using this factor, you can calibrate the SIDRA Standard capacity model to allow for less restricted (higher) capacity and more restricted (lower) capacity. Increasing the factor will provide reduced roundabout capacity, whereas lowering the factor will increase available roundabout capacity. For most analyses, this value should be increased to 1.1 or 1.2. Refer to [[#Table 905.3.5.2.2.1, SIDRA Lane Geometry: Typical User-Adjusted Parameters(When Field Data is Not Available)|Table 905.3.5.2.2.1]] for full description.
:• '''Lane Blockage Calibration Factor''' (located in the “Lane Movements” dialog box): The factor is specified for each lane movement and is used to adjust the effect of the downstream lane blockage (queue spillback) on the upstream lane capacity.
::o SIDRA default value is 1.0.
::o Values below 1.0 will decrease the effects of lane blockage
::o Values over 1.0 will increase the effect of lane blockage.
:'''• Entry/Circulating Flow Adjustment''' (located in the “Roundabouts” dialog box): The user can calibrate SIDRA for unbalanced flow conditions by specifying an adjustment level for the ratio of arrival flow rate to circulation flow rate. According to the level chosen, the follow-up headway and critical gap values are decreased (therefore capacity increased) as a function of the ratio of arrival flow to circulating flow in order to avoid underestimation of capacities at low circulating flows when the arrival flow rate is high. The user can choose the level of this adjustment (high, medium, low, none) according to the observed or expected local driver behavior characteristics. The default value is “None” for the “US HCM (Customary)” setup.

'''SIDRA Results and Presentation'''

After verifying that all input parameters into SIDRA are correct, it is important to run the “Process All Site(s)” button in the top left of the SIDRA interface. This will process all output information for the SIDRA intersection(s). Additionally, any subsequent revisions to an intersection after it has been processed will require the site to be processed again.

SIDRA produces several output summaries and displays that can be accessed in the bottom left of the user interface. MoDOT recommends using the Movement Summary to document roundabout measures of effectiveness (MOEs). The Detailed Output is also available if more detail is needed for a particular result.

If using illustrative outputs, the following outputs may be considered:
:• Control Delay Movement Display
:• LOS Movement Display
:• Degree of Saturation Movement Display
:• 95<sup>th</sup> Percentile Vehicle Queue Movement Display.

The primary MOEs for a roundabout include degree of saturation (v/c ratio), delay, LOS, queuing, and stop rates. These MOEs are summarized in a SIDRA Movement summary table and are highlighted in Figure 905.3.5.2.2.8. The user should take a comprehensive approach to roundabout analysis and be sure to assess all primary MOEs as part of the big picture of roundabout operations. For instance, if a LOS is reported as a D or better while v/c or queue lengths reflect poor operations, then the intersection or lane group could be considered as having the equivalent of a failing LOS.

'''Note:''' A degree of saturation of 0.85 v/c or less is desired for each lane group. If the degree of saturation is greater than 0.85, then the analyst is encouraged to perform sensitivity analysis to determine the influence of volumes on roundabout delays and queues.

[[image:905.3.5.2.2.8.jpg|center|1050px|thumb|'''<center>Figure 905.3.5.2.2.8, SIDRA Movement Summary Table Example
</center>]]

===905.3.5.2.3 Synchro===

Trafficware’s Synchro is a deterministic software application that supports HCM methodologies and the Intersection Capacity Utilization method for determining intersection capacity. Synchro is ideally used to analyze arterials and networks of multiple signalized and/or stop/yield-controlled intersections. The Synchro software application allows users to code roadway networks in a map-based interface (with aerial imagery overlays if desired) in addition to specifying key parameters in roadway link and intersection node tables. Then the user can specify the types of MOEs to quantify in auto-generated summary reports (refer to [[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to SynchroSimTraffic.docx|Accompaniment to Synchro/SimTraffic]] for more information).

'''HCM vs. Synchro'''

Synchro calculations are based off HCM methodologies. However, Synchro delay calculations will differ from the HCM results due to some differences. The HCM method uses one cycle length and one average traffic volume to represent the analysis period. In contrast, Synchro uses a percentile delay method for calculating the delay for signalized intersections, which is based on five different volume and cycle lengths (percentile volumes and green times). The final Synchro calculated delay is a weighted average of five representative delays.

The five representative delay scenarios modeled include the 90<sup>th</sup>, 70<sup>th</sup>, 50<sup>th</sup>, 30<sup>th</sup>, and 10<sup>th</sup> percentiles. Traffic volumes for each approach are adjusted up or down to model these percentile scenarios. For instance, if traffic were to be observed for 100 cycles, 90th percentile would be busier than 89 other cycles. Generally, HCM and Synchro results will be similar (refer to [[#Table 905.3.5.2.3.1, Methodology Differences in Synchro|Table 905.3.5.2.3.1]]) if the actuated green times are used in the HCM method. SimTraffic results, however, are based on the “observed” delay in the SimTraffic microsimulation model runs and could reasonably deviate from the HCM and Synchro results. Therefore, it is reasonable for different methodologies and/or tools to produce different results.

'''Project Purpose'''

The purpose for which Synchro/SimTraffic is being used will determine the level of detail, precision of the input data, the number of default values, and the desired accuracy of results. The Synchro/SimTraffic parameters described in EPG 905.3.5.2.3 Synchro and EPG 905.3.5.3.1 SimTraffic are intended primarily for capacity analysis. The setting parameters identified in this guidance can be applicable to optimizing traffic signals, but signal timing optimizing projects typically utilize more field and signal timing plan data that is context-sensitive to the particular signal(s). It is recommended that Synchro/SimTraffic should NOT be used for freeway analysis.

'''Synchro Report Settings'''

Synchro uses two different methods to calculate and report signalized intersection delays: the HCM method and the Synchro Percentile delay method. In most situations, the delays calculated by both methodologies are similar and will be within a few seconds of each other. Table 905.3.5.2.3.1 highlights the key differences in these two methods. The method to be used should be discussed during scoping and documented in the analysis report.
<center>
====Table 905.3.5.2.3.1, Methodology Differences in Synchro====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE"| Limitation!!style="background:#BEBEBE"| Synchro Percentile Delay Method!!style="background:#BEBEBE"| HCM 6<sup>th</sup> Edition
|-
|'''Spillback and Starvation Delay (caused by closely spaced intersections)'''||Includes a method to model this delay when intersections are close to each other||Does not include any delay for queue spillback or starvation 
|-
|'''Actuated Green Time Calculations'''|||Synchro determines actuated green times||Includes computational engines
|-
|'''Right Turn on Red (RTOR)'''||Synchro calculates a RTOR saturation flow rate, and increases the right-turn capacity.||The RTOR is a volume input by the user and is used as a volume reduction (not a capacity increase). 
|-
|'''Turn Pocket Overflow'''||colspan="2"|Both methods have this limitation. If vehicles are spilling out of a turn pocket or through vehicles are blocking a turn pocket, the delay that would occur in the field is not included in the models’ delay output.
|-
|colspan="3"|'''Note:''' Based on Table 19-2 in ''Synchro 10.1 User’s Guide''.
|}
</center>
Refer to Section D.11 in [[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to SynchroSimTraffic.docx|Accompaniment to Synchro/SimTraffic]] for more information on selecting the analysis method in the Synchro Report Settings dialog box.

'''Synchro Coding Recommendations'''

Coding roadway networks in Synchro is intuitive and can primarily be accomplished using icons in the Home tab. For a detailed introduction to coding, it is recommended that the user access the Synchro User Guide in the Help tab of Synchro. (Refer to Figure 905.3.5.2.3.2).

[[image:905.3.5.2.3.2.jpg|center|700px|thumb|<center>'''Figure 905.3.5.2.3.2, Synchro User Guide'''</center>]]

Since effective network coding can be nuanced, best practices to be aware of include the following:
:• Intersection approaches should be coded using cardinal directions only (e.g., north, south, east, and west). Other approach directions (e.g., northeast, southeast, northwest, and southwest) could potentially prevent Synchro from discerning turn movements from through movements. This would lead to inaccurate capacity and queueing results. However, if non-cardinal directions are needed for an intersection (an example would be an intersection with more than 4 legs), then be sure to thoroughly check that all appropriate traffic movements are properly assigned.
:• The analysis period should remain at the Synchro-default of 15 minutes.
:• The absence of traffic volumes on certain traffic movements could potentially lead Synchro to incorrectly calculate one or more movements as being prohibited. It is advised that traffic volumes should be changed from any value less than 4 vehicles per hour (vph) to 4 vph for non-restricted movements ('''Note:''' this is a Synchro-only issue and is not a concern for other tools such as HCS).
:• All external links should extend reasonable distances from an intersection (at least 1,000 feet if not constrained by nearby intersections) to ensure adequate queueing can be calculated in subsequent SimTraffic runs.
[[image:905.3.5.2.3.4.jpg|right|280px|thumb|<center>'''Figure 905.3.5.2.3.3, Conflicting Movements Example</center>''']]
:• The link speed should represent the posted or proposed speed limit of the actual roadway.
:• Overlaps between conflicting traffic movements should be avoided. Figure 905.3.5.2.3.3 shows an example of how conflicting movements can be identified using both the ring-and-barrier diagram and error notifications that will appear at the bottom of the Timing Settings table. Additionally, a common error to avoid is the coding of conflicts between U-turn and right-turn movements.
:• If analyzing median-controlled facilities where each bound is coded as a separate link, then left turns or U-turns should be modeled on separate links. On these short turn-only median links, both the “Simulation Left Turn Speed” entering the link and the link speed should be 10 mph below the speed limit. Refer to Figure 905.3.5.2.3.4.
:[[image:905.3.5.2.3.3.jpg|center|400px|thumb|<center>'''Figure 905.3.5.2.3.4, U-Turn Speed Example<br/>Note:''' Link speeds displayed on links</center>]]

:• Be aware of and document locations that could impact lane usage (e.g., a lane merge beyond an intersection or an advanced turn lane at a diamond interchange). Modify the lane utilization factor where appropriate (see [[#Table 905.3.5.2.3.6, Synchro Lane Settings: Typical User-Adjusted Attributes(When Field Data is Not Available)|Table 905.3.5.2.3.6]]).
:• Use the Coding Error Check. Click on “Options” and then “Error Check” to identify all errors and warnings by location (e.g., node number and traffic movement) and error type. Try to address all errors and warnings if possible.
 
'''Coding with Cluster Editor'''

The cluster editor can be activated by selecting the “Cluster Editor” button from the Signal Timing group on the Home tab. The cluster editor allows multiple intersections to share one controller (Group control) through interactive selections and color coding in a dialog box. The cluster editor is often used in conjunction with the Ring and Barrier Designer. The cluster editor is especially useful for assigning group control to diamond interchanges, closely spaced intersections, and arterials with wide medians modeled as two nodes. Some important items to be aware of for cluster editor include:
:• The smallest node number in the cluster is the controller number that will be used for data exchange.
:• With group control, it is recommended that each intersection use phases in one ring only. All phases for one node should, ideally, be contained in one ring.

'''Key Synchro Parameter Recommendations'''

[[#Table 905.3.5.2.3.5, Synchro Intersection Signal/Node Settings: Typical User-Adjusted Attributes(When Field Data is Not Available)|Table 905.3.5.2.3.5]], [[#Table 905.3.5.2.3.6, Synchro Lane Settings: Typical User-Adjusted Attributes(When Field Data is Not Available)|Table 905.3.5.2.3.6]], and [[#Table 905.3.5.2.3.7, Synchro Volume, Timing, & Phasing Settings: Typical User-Adjusted Attributes(When Field Data is Not Available)|Table 905.3.5.2.3.7]] summarize key Synchro parameters with specific MoDOT guidance for proper application. In general, field data should be used when available. In the absence of field data, the tables below provide some suggested parameter values.

'''Note:''' Simulation Settings parameters are summarized in [[#905.3.5.3.1 SimTraffic|EPG 905.3.5.3.1 SimTraffic]]. Although Simulation Settings values are entered in the Synchro user interface, these parameters tend to be either visual or non-applicable in Synchro, but influence driver simulation settings in SimTraffic.

<center>

====Table 905.3.5.2.3.5, Synchro Intersection Signal/Node Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE"| Parameter(s)!!style="background:#BEBEBE"| Parameter Description!!style="background:#BEBEBE"| Suggested/Typical Value(s)
|-
|Node#<sup>'''1'''</sup>||Unique number assigned to all intersections and non-intersection nodes in Synchro. The Node# can contain a maximum of 4 digits.||'''Signalized Intersection:''' Use the first 4 digits of a signal ID number (MoDOT signal IDs range from 1xxx to 8xxx).<br/>'''Unsignalized Intersection:''' Use a 4-digit value that starts with a “9” (9xxx).
|-
|Z Elevation (ft)||The elevation (in feet) of the nodes relative to the project-specific baseline elevation (the default Synchro value is 0 feet).||To create an overpass, assign higher Z coordinate elevation values to the nodes adjacent to the overpass link (used for visual purposes only).
|-
|Referenced to||The defined point that creates an association between a local, signalized intersection’s clock and the master clock for multiple, signalized intersections in a coordinated signal system. Selection options include:<br/>'''Begin of Green:''' Offsets are referenced to the beginning of the last reference phase to turn green (Traditional NEMA referencing and the Synchro default for new intersections).<br/>'''Begin of Yellow:''' Offsets are referenced to the beginning of the first reference phase to turn yellow (this is 170 style referencing).<br/>'''Begin of Red:''' Offsets are referenced to the beginning of the first reference phase to turn red.<br/>'''TS2 – 1<sup>st</sup> Green:''' Offsets are referenced to the beginning of the first reference phase to turn green (used with some NEMA TS2 controllers).<br/>'''170 Style:''' Referenced to start FDW or start of yellow.||The Synchro model should match the controller where possible.<br/>For additional information about how to appropriately match to the controller, refer to the sources:<br/>&nbsp;&nbsp;&nbsp;• ''[https://ops.fhwa.dot.gov/publications/fhwahop08024/chapter6.htm#6.3 FHWA Signal Timing Manual 1<sup>st</sup> Edition]'': Refer to Section 6.3.4 and Figure 6-7. NCHRP 812 supersedes this document.<br/>&nbsp;&nbsp;&nbsp;• ''[http://www.trb.org/OperationsTrafficManagement/Blurbs/173121.aspx NCHRP 812: Signal Timing 2<sup>nd</sup> Edition]''
|-
|Reference Phase||The Reference Phase is used to determine the coordinated phase(s) for an actuated signal.||Select the appropriate reference phase as determined in the coordinated signal plan (if nothing specified, refer to phases 2 and 6).
|-
|Coordination Mode||The coordinated phases associated with the arterial street.||Select one of the two options below that is most appropriate for the intersection(s) being analyzed:<br/>'''“Fixed” Force-Off (Synchro default):''' A mode of split management used with coordinated operations under which force-off points cannot move. Under this mode, uncoordinated phases can utilize unused time from previous phases.<br/>'''“Floating” Force-Off:''' Force-off points can move depending on the demand of previous phases. Under this mode, uncoordinated phases are limited to their defined split times, and all unused time is dedicated to the coordinated phases.
|-
|colspan="3"|<sup>'''1</sup> If there are multiple intersections with other, similar Node #’s:''' Use the “Select Int.” button to confirm that the desired new node # does not already exist and to adjust the other intersection’s node # as needed. If Synchro identifies two nodes with the same ID #, then it will automatically swap intersection node #’s.
|}

====Table 905.3.5.2.3.6, Synchro Lane Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
! style="background:#BEBEBE"| Parameter(s)!!style="background:#BEBEBE"| Parameter Description!!style="background:#BEBEBE"| Suggested/Typical Value(s)
|-
|Grade (%)||The grade will impact the saturation flow rate. For instance, a negative grade (downhill) will increase the saturation flow rate.<br/>An example would be a one lane approach with a saturated flow rate of 1,780 pc/h/ln (0% grade) increasing to 1,833 pc/h/ln with a -6% grade. So, in this example, an approximate 3% saturation flow rate increase provides a 6% reduction in grade.<br/>MoDOT TMS and Google Earth are potential data source for grades.||'''Flat Grade:''' 0%<br/>'''Moderate Grade:''' 3%<br/>'''Steep Grade:''' 6%
|-
|Lane Utilization Factor||colspan="2"|Determines how the traffic volumes assigned to a lane group are distributed across each lane. A value of 1 means equal distribution across all lanes and less than 1 means the saturation flow rate is low because all lanes are not working at full capacity. The available range to override in Synchro is from 0.2 to 1.0.<br/>Synchro automatically defaults to lane utilization factor values to match the number and type of lanes in a lane group. These factors are based on Exhibit 19-15 in the HCM, 6<sup>th</sup> Edition, and can be found in Table 8-2 of the ''Synchro 10.1 Users Guide''.<br/>Common situations that would lead to the user needing to override default values include the dropping of downstream lanes and downstream turning locations that would cause a higher proportion of vehicles to be in a particular lane to turn, such as a diamond interchange with advanced left turn lanes. The NCHRP 707, ''Guidelines on the Use of Auxiliary Through Lanes at Signalized Intersections'', provides good information on this topic, including a spreadsheet to help calculate auxiliary through lane utilization:<br/>&nbsp;&nbsp;&nbsp;[http://www.trb.org/Publications/Blurbs/166520.aspx '''NCHRP 707 PDF Report'''] <br/>&nbsp;&nbsp;&nbsp;[http://onlinepubs.trb.org/onlinepubs/nchrp/docs/NCHRP03-98_CombinedComputationalEngine.xlsx '''NCHRP 707 Spreadsheet'''] 
|-
|Saturation Flow Rate||The equivalent hourly rate at which previously queued vehicles can traverse an intersection approach under prevailing conditions, assuming the green signal is available at all times and no lost times are experienced. Saturation flow rate is expressed as an expected average hourly rate in units of passenger car equivalents per hour per lane (pc/h/ln).<br/>The HCM states that the base saturation flow rate for a metropolitan area (greater than 250,000 population) is 1,900 pc/h/ln and the base saturation flow rate non-urban areas is 1,750 pc/h/ln (the Synchro default is set to be 1,900 pc/h/ln).||The base/ideal saturated flow rate is then adjusted by various factors to account for prevailing geometric and traffic conditions in the field. This adjustment will calculate the saturated flow rate, which typically results in a final rate that is lower than the base/ideal rate. Synchro will automatically calculate saturated flow rates for every traffic movement and display these auto-calculated values in the Lane Settings table and in Synchro reports. The saturated flow rate can be overridden using field data and/or for calibration purposes.
|-
|Right Turn Channelized||colspan="2"|'''None:''' No right-turn channelization; '''Yield:''' Yield sign with no phases assigned; '''Stop:''' Stop sign with no phases assigned;<br/>'''Free:''' Phase is "free" (100% green time); '''Signal:''' Movement is controlled by the signal
|-
|Curb Radius (ft)||Value only appears if Right Turn Channelized is selected. Curb Radius specifies the horizontal curvature of the street intersection. ||
Note that this is strictly a visual item that does not impact traffic calculations, so long as the same traffic control measure is applied for the movement (signal, yield, free, etc.)
|}

====Table 905.3.5.2.3.7, Synchro Volume, Timing, & Phasing Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Dialog Box !! style="background:#BEBEBE"| Parameter(s)!!style="background:#BEBEBE"| Parameter Description!!style="background:#BEBEBE"| Suggested/Typical Value(s)
|-
|rowspan="3"|Volume Settings||Adjacent Parking Lane and Parking Maneuvers (#/hr)||colspan="2" width="650"|Check the box and enter data if there is on-street parking AND that it impedes traffic flow.
|-
|Traffic from Mid-Block (%)||colspan="2"|Use default value of 0%.<br/>(Using mid-block volumes can be evaluated on a case-by-case basis as necessary.)
|-
|Link OD (Origin-Destination) Volumes||colspan="2"|All approaches that connect to an adjacent intersection have a button available in the Link O-D Volumes row. The user can activate the settings by clicking on this button: [[image:Table fig 905.3.5.2.3.7.jpg|60px]]<br/>Link OD volumes allow detailed control over the origin and destination flows between two adjacent intersections. Volume balancing can reduce or eliminate certain turn combinations. In most cases, Link O-D volumes are not needed since O-D volumes make little difference to the timing plan optimization. The most common use is to prevent vehicles from turning left twice (i.e., a U-turn) at a freeway or wide median arterial.<br/>For a full, detailed guide on how to use the Link OD Volumes feature, refer to pages 9-6 through 9-9 in the ''Synchro Studio 10 User Guide''.
|-
|Timing Settings||Permitted Flashing Yellow Arrow||colspan="2"|The “Permitted Flashing Yellow” parameter is a checkbox in the Synchro Timing Settings grid that is only available when the signal turn type is selected to be Dallas Permitted plus protected (“D.P+P”), permitted plus protected (“pm+pt”), or “Reserved.” For the purposes of SimTraffic, a flashing yellow arrow turn will operate the same as a permissive turn, so the selection of the “Permitted Flashing Yellow” checkbox will not affect analysis results and will only be displayed visually in SimTraffic.
|-
|Phasing Settings<sup>'''1'''</sup>||Pedestrian Phase||colspan="2"|Select checkbox if there is a pedestrian movement for a phase.
|-
|colspan="4" width="900"|<sup>'''1'''</sup> To model a leading pedestrian interval (LPI) in Synchro, the analyst would assign a separate phase for the pedestrians (such as phase 9 and 10) and edit the ring/barrier structure for it to be serviced before the side street vehicle phase. However, for this to model correctly in SimTraffic it is important to note that pedestrian volumes would need to be coded into Synchro and the proper detector settings be entered so that the phase(s) will be serviced in simulation.<br/>With this method, the split shown in Synchro for the side street vehicular phase will not be the split that is programmed into a signal controller, which could be confusing when exporting timings. There are other nuances that would need to be addressed so any context as to how the analyst desires to use LPIs would help determine if other software would be appropriate (i.e., will the analysis be used for capacity or signal timing coordination?). LPIs can have safety benefits for pedestrians but can also negatively impact the operations of signals.
|}
</center>

'''Optimizing Signals in Synchro'''

Synchro contains a number of optimization functions. It is important to understand what each function does and use the optimization steps in the correct order:
:1. '''Develop Intersection Timing Plans''' – Develop timing plans for individual intersections through the following steps:
:::a. Enter lane data
:::b. Enter volume data
:::c. Set up phase numbers for each movement
:::d. Optimize cycle lengths and splits using the “Optimize” buttons in the Node Settings dialog box
:::e. Check capacity
:::f. Check for coding errors.
:2. '''Partition Network (Optional Step)''' – Use the “Partition Network” command under the Optimize tab in Synchro to divide the network into multiple zones. Assigning zone numbers can also be assigned manually in Node Settings.
[[image:905.3.5.2.3.8.jpg|right|450px|thumb|<center>'''Figure 905.3.5.2.3.8, Synchro ''Optimize Cycle'' Lengths Dialog Box'''</center>]]
:3. '''Optimize Network Cycle Length''' – Determine a system cycle length (if zones are created, then a consistent cycle length for each zone). Optimize using the following steps, which inform how to complete the Optimize Cycle Lengths dialog box (refer to Figure 905.3.5.2.3.8):
:::a. '''Minimum, Maximum, and Increment Cycle Length:''' The optimizer will evaluate every cycle length between the minimum and maximum at increment intervals. If the values are set to 80, 100, and 10, the optimizer will evaluate cycle lengths of 80, 90, and 100 seconds. Recommend 60, 240, 10.
:::b. '''Allow Uncoordinated:''' This option setting determines how frequently signals will be recommended to remain uncoordinated. Recommend “Sometimes (50)”
:::c. '''Allow Half Cycle Length:''' With this option, some intersections would be tested at half cycle length. Recommend “checked”
:::d. '''Preserve Files:''' With this option, a file is saved for each cycle length. Recommend “unchecked”
:::e. '''Optimize Phase Sequence:''' If this is checked, leading and lagging left-turn combinations will be tested. However, lead/lag combinations will NOT be tested if the “Allow Lead/Lag Optimize?” setting is not checked in the Phasing table. Recommend “checked”
:::f. '''Offset Optimization:''' The options (“Quick,” “Medium,” or Extensive”) determine the level of detail and speed that will be used for analysis. Recommend “Extensive”
:::g. '''Weighting:''' Choose the default “No Weighting” option
:::h. '''Scope:''' Choose if the analysis is for a particular zone or the entire network
:::i. '''Manual/Automatic:''' Selecting manual will create a summary table of cycle length and MOE combination options that the user can select from. Recommend “Manual”.
:4. '''Optimize Offsets and Lead/Lag Phasing''' – Tests all possible offset and lead-lag combinations to select a timing plan that minimizes delays on the links between the intersections. This function allows for the following options:
:::a. Splits to remain the same or to be optimized. Recommend “Optimize”
:::b. For a quick or longer, more detailed optimization. Recommend “Best Timing Plans”
:::c. For the “Weighting the Reference Phase” option to be selected (which would focus the offset optimization routine on minimizing delay for the reference phases). Recommend “No Weight”
:::d. A zone or a network scope.

'''Queue Lengths in Synchro/SimTraffic'''

Synchro reports calculated 50th percentile and 95<sup>th</sup> percentile queue lengths. SimTraffic reports the simulated average, maximum, and 95<sup>th</sup> percentile queue lengths. Both programs estimate queue lengths to the nearest foot. The queue lengths are determined using different methods between Synchro and SimTraffic.

Since SimTraffic is a micro-simulation program, it actually “observes” each individual vehicle and documents whenever a vehicle is traveling less than 10 feet per second and behind a queue of vehicles. This process can often lead to different queuing results than Synchro, especially when queuing vehicles from adjacent intersections are influencing the subject intersection. '''It is advised that Synchro 95<sup>th</sup> Percentile Queue lengths and SimTraffic Maximum Queue lengths be the primary queue metrics that are analyzed and reported.''' In particular, Synchro 95<sup>th</sup>Percentile Queue lengths that are over or approaching capacity should be compared to SimTraffic Maximum Queue results to verify the queuing issue.

'''Synchro/SimTraffic Storage Lane Review'''

A mitigating strategy for a project could include recommending longer and/or additional storage lanes. In order to determine appropriate storage lane recommendations, both Synchro and SimTraffic output should be reviewed. Table 905.3.5.2.3.9 provides a summary of the queues reported in Synchro and SimTraffic.
<Center>

====Table 905.3.5.2.3.9, Queue Lengths in Synchro & SimTraffic====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Synchro Queues Reported!! style="background:#BEBEBE"| SimTraffic Queues Reported
|-
|'''Unsignalized Queues''' – Computed according to the HCM method||'''Maximum''' – The maximum observed distance from the stop bar to the back of queue over the analysis period. Note that it is limited by the length of the link. It is recorded every two minutes during the simulation.
|-
|'''50<sup>th</sup> Percentile''' – The maximum back of queue on a typical cycle. Computed using a formula.||'''Average''' – The average of the observed maximum queues for each of the recorded two-minute periods
|-
|'''95<sup>th</sup> Percentile''' – The maximum back of queue with 95<sup>th</sup> percentile traffic volumes. Computed using a formula.||'''95<sup>th</sup> Percentile''' – A computed queue that is computed as 1.65 standard deviations above the average queue. Therefore, the 95<sup>th</sup> percentile queue can be greater than the maximum queue and is not limited by the length of the link.
|-
!style="background:#BEBEBE"| Synchro Analysis Conclusion: !!style="background:#BEBEBE"|SimTraffic Analysis Conclusion:
|-
|Use the 95<sup>th</sup> Percentile Queue to assess delay and/or queueing problems. For locations where this delay and queueing problems are a concern, then compare it to SimTraffic’s Maximum Queue.||Use the Maximum Queue since it is a simulated, “observed” queue that accounts for traffic variability and adjacent intersections.
|}
</center>
'''Synchro Review:''' If an approach or movement has a 95<sup>th</sup> Percentile Queue length that is flagged with a “#” or “m” or a 50th Percentile flagged with a “~,” then the intersection should be thoroughly reviewed for potential improvement opportunities since there could be serious delay and/or queuing problems. Additionally, the Synchro output should be compared to SimTraffic output (or other analysis tools such as VISSIM), if available, to better understand what is causing the delay. Additional documentation should be provided if the following footnotes are displayed in a Synchro report:
:• “~” indicates the approach is above capacity for the 50<sup>th</sup> percentile traffic and the queue length could be longer
:• “#” indicates that the volume for the 95<sup>th</sup> percentile cycle exceeds capacity
:• “m” indicates that volume for the 95<sup>th</sup> Percentile Queue is metered by an upstream signal.

'''SimTraffic Review:''' All instances where the SimTraffic maximum queue length (maximum observed queue) exceeds the storage bay length should be addressed. The '''SimTraffic Maximum Queue''' or the '''Synchro 95<sup>th</sup> Percentile Queue''', whichever is higher, should be used in determining recommended storage lane lengths. '''Do NOT use the SimTraffic 95<sup>th</sup> percentile queue since it is statistically estimated from the mean queue and the standard deviation.''' The ''Synchro 10.1 User’s Guide'' states that, “the (SimTraffic) 95<sup>th</sup> Queue is not necessarily ever observed, it is simply based on statistical calculations.” Excessive queuing identified in SimTraffic should be reviewed for appropriateness and unrealistic lane blockages.

==905.3.5.3 Microsimulation Models==
Microsimulation models simulate the movement of individual vehicles based on vehicle and driver behavior theories. These models are good for large-scale transportation facilities and for analyzing interactions with other vehicles and adjacent intersections to help determine MOEs. An important consideration is determining if the project being assessed is appropriate for the extra levels of effort and large computer processing time and storage requirements often needed for microsimulation models. Common microsimulation tools that will be summarized in EPG 905.3.5.3 Microsimulation Models include SimTraffic and VISSIM.

For all microsimulation models it is important to complete multiple simulation runs per peak hour scenario. Completing multiple simulation runs provides the following benefits:
:• Accounts for the variability in traffic flow patterns (to complete only one simulation run would be the equivalent of assuming that peak hour traffic on one day is representative of traffic on all days throughout the year)
:• To verify model results by minimizing the influence of “outlier” runs
:• To accurately quantify the results of higher delay and queues.

===905.3.5.3.1 SimTraffic===

SimTraffic is microsimulation software that simulates the movement of individual vehicles based on vehicle and driver behavior theories. SimTraffic simulates the coded transportation network and measures the performance of each individual vehicle as they move through the system. Since each individual vehicle will react differently to the influences of other vehicles, pedestrians, bicyclists, roadway geometry, and grades, models with the same geometric and volume inputs will generate slightly different results, similar to how an intersection in the field will perform differently day-to-day under otherwise identical conditions.

'''Key Simulation Settings Recommendations'''

Tables 29, 30, and 31 summarize key Synchro/SimTraffic parameters with specific MoDOT guidance for proper application. In general, field data should be used when available. In the absence of field data, the tables below provide some suggested parameter values.

Note: Simulation Settings parameters are summarized in EPG 905.3.5.3.1 SimTraffic. Although Simulation Settings values are entered in the Synchro user interface, these parameters tend to be either visual or non-applicable in Synchro, but influence driver simulation settings in SimTraffic.
<center>
====Table 905.3.5.3.1.1, Synchro/SimTraffic Simulation Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Parameter(s)!! style="background:#BEBEBE"| Parameter Description!! style="background:#BEBEBE"|Suggested/Typical Value(s)
|-
|Lane Alignment||This setting determines how lanes align through an intersection.<br/>Refer to Figure 905.3.5.3.1.1 (Figure 13-2 from ''Synchro Studio 10'' User Guide) to the right.<br/>'''Synchro-default values:'''<br/>“Right” for right turns, “Left” for left turns, & “Right-NA” for U-Turns.<br/>For more discussion on the impacts that the Lane Alignment can have on vehicles simulated in SimTraffic, please refer to [https://www.trafficware.com/blog/lane-alignment Trafficware blog].||[[image:905.3.5.3.1.1.jpg|center|575px|thumb|<center>'''Figure 905.3.5.3.1.1, Lane Alignment Examples'''<br/>'''Note:''' Ensure default settings are correct when the number of receiving lanes exceeds the approach lanes.]]
|-
|Enter Blocked Intersection||The “Entered Blocked Intersection” setting controls simulation modeling gridlock avoidance (e.g., a selection of “1” or “2” will allow 1 or 2 vehicles to enter a blocked intersection.)<br/>The following node types generally correspond to the following selection values:<br/>&nbsp;&nbsp;&nbsp;• '''Intersections:''' “No”<br/>&nbsp;&nbsp;&nbsp;• '''Bends/Ramp Junctions:''' “Yes”<br/>&nbsp;&nbsp;&nbsp;• '''High Speed Approaches/Movements:''' “No”<br/>&nbsp;&nbsp;&nbsp;• '''Unsignalized Intersection Side Street:''' “1” or “2”||For most MoDOT applications, set the parameter to “1” unless otherwise specified or not appropriate.
|-
|Two-Way-Left-Turn-Lane (TWLTL) Median||A visual-only display of a TWLTL median (simulated vehicles will not actually use the TWLTL median).||User-defined selection
|}

====Table 905.3.5.3.1.2, Synchro/SimTraffic Simulation Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Parameter(s)!! style="background:#BEBEBE"| Parameter Description!! style="background:#BEBEBE"|Suggested/Typical Value(s)
|-
|Median Width (ft)||This parameter determines the link’s median width. Note that left-turn lanes are considered to be positioned in the median even if they are not defined as storage lanes. This setting is Synchro-calculated, but it can be overridden.<br/>See Figure 905.3.5.3.1.2 (Figure 13-4 from ''Synchro Studio 10'' User Guide) for examples.||[[image:905.3.5.3.1.2.jpg|center|625px|thumb|<center>'''Figure 905.3.5.3.1.2, Median Width Examples'''</center>]]
|-
|Link Offset (ft)||colspan="2"|Setting is used to offset the roadway alignment to the right or left of the centerline. This can be used to create a dog-leg intersection, if there are no internal stop bars. See Figure 905.3.5.3.1.3 (Figure 13-5 from ''Synchro Studio 10 User'' Guide) for examples.<br/>'''Synchro-default value:''' 0 ft
|}


[[image:905.3.5.3.1.3.jpg|center|825px|thumb|<center>'''Figure 905.3.5.3.1.3, Link Offset Examples'''</center>]]

====Table 905.3.5.3.1.4, Synchro/SimTraffic Simulation Settings: Typical User-Adjusted Attributes<br/>(When Field Data is Not Available)====
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Parameter(s)!! style="background:#BEBEBE"| Parameter Description!! style="background:#BEBEBE"|Suggested/Typical Value(s)
|-
|Turning Speed (mph)<sup>'''1'''</sup>||The turning speed of vehicles while inside the intersection (utilized in SimTraffic only, not Synchro).||'''Synchro-default left-turn value:''' 15 mph<br/>'''Synchro-default right-turn value:''' 9 mph
|-
|colspan="3"|<sup>'''1'''</sup> It is recommended to use the Synchro/SimTraffic default values for this attribute. However, for intersections with large turning radii and for the modeling of intersections with freeway entrance/exit slip ramps, the turning speeds can be adjusted higher IF set to reasonable ranges. The best way to determine a reasonable range is to review field data and to review if the simulated turning movement saturated flow rates are reasonable. Refer to Figure 905.3.5.3.1.5 for a sample of right-turn speeds for different turning types, as observed by MoDOT.
|}
</center>

[[image:905.3.5.3.1.5.jpg|center|925px|thumb|<center>'''Figure 905.3.5.3.1.5, MoDOT Field Data Sample of Right-Turn Speeds'''</center>]]

'''SimTraffic Calibration'''

Complete the following steps to utilize SimTraffic simulation and animation:
:1. Open SimTraffic by clicking on the SimTraffic icon under “Home”/“Simulation”
:2. Coding Error Check – Click on “Options” and then “Coding Error Check” to identify all errors and warnings by location (e.g., node number and traffic movement) and error type. Try to address all errors and warnings if possible, which may require making coding revisions in Synchro.
:3. Establish SimTraffic calibration parameters using the following 4 tables under the “Calibration” section:
:::a. Intervals & Volumes – Networks should be seeded for a period long enough to traverse the two most distant points of the network, including stops prior to recording, with a minimum of 15 minutes. The seeding time should also be longer than the maximum cycle length used in the network. The recording interval duration used in SimTraffic should be 60 minutes unless otherwise justified. It is recommended to break the recording duration into 15-minute intervals to utilize the “PHF Adjust” and “AntiPHF Adjust” features. It is recommended to verify SimTraffic throughput reports against Synchro hourly volumes.
:::b. Drivers – '''''Start with default values.''''' When vehicles are created, they are randomly assigned a driver type between 1 and 10. Each driver type represents 10% of the driving population with driver type 1 being the most conservative and driver type 10 being the most aggressive.
:::c. Vehicles – '''''Start with default values.''''' This page can be used to view and edit the vehicle characteristics (refer to Figure 905.3.5.3.1.6). Note that the total proportion of heavy vehicles (among all vehicles) is determined in Synchro and that the vehicle occurrence percentages on this page are among the total number of heavy vehicles established already. To simulate a higher proportion of certain heavy vehicle types on known freight corridors, the proportions of the “Truck SU,” “SemiTrk1,” “SemiTrk2,” “Truck DB,” and/or “Bus” could be adjusted higher (while lowering another, lesser occurring heavy vehicle type).

[[image:905.3.5.3.1.6.jpg|center|925px|thumb|<center>'''Figure 905.3.5.3.1.6, SimTraffic Vehicle Parameters'''</center>]]

:::d. UTDF (Data) Options – This page allows volume counts and timing plans to be read from an external data source.
:4. Refer to both '''SimTraffic Model Runs''' and '''SimTraffic Report Settings''' for documentation and establishing multiple runs.

'''SimTraffic Model Runs'''

[[#905.3.5.3 Microsimulation Models|EPG 905.3.5.3 Microsimulation Models]] summarizes the importance of completing multiple model simulation runs. It is advised that between 5 and 9 simulation runs be completed in SimTraffic for each peak hour scenario (e.g., a minimum of 10 cumulative runs should be completed if analyzing both AM and PM peak hours).

If determining when to complete 5 Simtraffic runs as opposed to 9 runs, it is advised that the modeler stick to the lower end of the range if there is a low volume demand and minimal congestion on the transportation network. It is advised that the modeler run a higher quantity of runs (in the acceptable range) if there is high delay and excessive queuing on the transportation network. No more than 9 runs per peak hour scenario would be needed since SimTraffic has a partner tool in Synchro, which results can be compared to for reasonableness.

'''SimTraffic Report Settings'''

Complete the following steps to document SimTraffic results through auto-generated reports created in the software.

:1. Select the appropriate report items by clicking on “Reports” and then “Create Reports” (multiple items can be selected using the “CTRL” button)
:2. Under the “Reports” tab, select the desired summaries as needed for the specific analysis type:
:::a. For a queueing and blocking report, select the “Queuing Information” checkbox
:::b. Select “Performance Report” to document network MOEs. Once selected, the user can select options in the “MOEs to include” list by holding CTRL and choosing multiple MOEs. For a capacity analysis, the following MOE items, at a minimum, should be selected:
::::i. All “Delay” options
::::ii. All “Network” options
::::iii. Under “Other,” select “Total Travel Distance,” “Total Travel Time,” and “Average Speed”
::::iv. Under “Section, Columns,” select “Intersection, Movement.” To see variability by run, select an option ending with “Run Number”
:3. Select the checkbox for multiple runs
:4. Under “Scope” (bottom of dialog box), select either a single intersection, zone, or the entire network
:5. Under the “Header” tab, establish header and footer project information in a similar manner as Synchro.
:6. Select the “Record Now” button to establish the number of desired simulation runs and to begin recording in SimTraffic (refer to guidance above on the number of model runs to complete).

'''Using SimTraffic to Mitigate Excessive Queuing'''

If determining appropriate storage bay lengths to use in a project’s “mitigation” scenario, then SimTraffic can be used to help determine the appropriate lengths to use. The user would complete the following steps:
:1. Develop a copy of the Synchro/SimTraffic file specific to this “Mitigation” scenario.
:2. In Synchro, remove the storage bay distance attributes at all intersections ('''Note:''' this removes the storage bay distance constraints and transforms the former storage lanes into full travel lanes). This will provide the turning movement with the storage capacity of the length of the roadway link. It will also allow SimTraffic to analyze what the queue lengths will be without the constraint of the storage bays lengths.
:3. Run SimTraffic at least five times for each peak hour scenario.
:4. Review the longest SimTraffic Maximum Queues for each location to determine a preliminary length to set the storage bay for these locations.
:5. Re-code the network to include new storage bay lengths, rounded up to the nearest 25 ft. from the Maximum Queue lengths.
:6. Finalize the Documentation.

===905.3.5.3.2 VISSIM===

====905.3.5.3.2.1 Introduction====

=====905.3.5.3.2.1.1 VISSIM Protocol Purpose=====
The purpose of this protocol is to guide those using VISSIM through the processes of model development, calibration, and post-processing. The goal of this VISSIM protocol, however, is not to provide an in-depth procedure for conducting microsimulation. Rather, the intent is to inform modelers of MoDOT’s preferred practices, thereby fostering quality and consistency among MoDOT projects and project deliverables.

The version of VISSIM used should be discussed and documented during the scoping phase of the project. It will not necessarily be the latest version of VISSIM that is available but will be affected by the version of VISSIM available to MoDOT as well as the version in which other existing models are coded. Once a model is calibrated, it is recommended to keep that model in the same version of VISSIM for the remainder of the project. VISSIM has numerous additional licenses for add-on features, so it is important to ensure that all necessary features are available to all parties at the outset of the project.

=====905.3.5.3.2.1.2 Summary of VISSIM Guidance Structure=====

This protocol presents:

[[#905.3.5.3.2.2 Base Model Development|EPG 905.3.5.3.2.2 Base Model Development]] provides guidance on setting up a microsimulation model in VISSIM, more specifically listing recommended parameter values that should be used when coding a VISSIM model as part of a MoDOT project.

[[#905.3.5.3.2.3 Error Correction, Calibration and Validation|EPG 905.3.5.3.2.3 Error Correction, Calibration and Validation]] describes how analysts should refine models before submitting them to MoDOT. EPG 905.3.5.3.2.3 provides some guidance on model troubleshooting, then gives recommendations on how analysts should calibrate their models to better replicate real-world traffic conditions. Lastly, EPG 905.3.5.3.2.3 explains how analysts can prove their model is calibrated through validation.

[[#905.3.5.3.2.4 Results and Presentation|EPG 905.3.5.3.2.4 Results and Presentation]] outlines what information should be submitted to MoDOT upon completion of a traffic study and how that information should be presented in a final report.

[[media:EPG 905.3 Transportation Impact Analysis, Technical References.docx|Technical References]] lists all documents used to guide the creation of this protocol, including transportation analysis guidance at the state and federal levels.

[[media:EPG 905.3 Transportation Impact Analysis, Accompaniment to VISSIM.docx|Typical VISSIM Parameters]] documents typical VISSIM input parameters that aid in communicating MoDOT’s VISSIM guidelines.

====905.3.5.3.2.2 Base Model Development====
=====905.3.5.3.2.2.1 Model Boundary=====
Because of the complexity of microsimulation and the amount of time required to complete traffic models, defining a clear model boundary at the outset of every project is vital. Selecting a boundary that is too large unnecessarily extends the amount of time required to complete the model, while selecting a boundary that is too small may not reasonably account for the influences of the surrounding transportation network. A proper model boundary is one that reasonably encompasses the extents of all design alternatives being evaluated, as well as all surrounding areas which may have an effect on traffic operations at the site of the proposed alternatives. Ultimately, the intent should be to include all traffic congestion relevant to the proposed alternatives without extending the limits of the boundary beyond what is necessary. Doing so allows the model to produce more accurate and all-inclusive predictions of travel conditions within the study area while keeping the model’s size manageable. The model boundary should be agreed upon by the project team, including FHWA when applicable, during project scoping. Below is guidance for typical model limits of different project types.

:• '''Freeways –''' at least one interchange beyond construction limits –including that interchange’s on and off-ramps closest to the construction at a minimum or an evaluation of the full adjacent interchanges if required and agreed upon by all stakeholders in the project scoping process
:• '''Ramp terminals –''' one major intersection beyond construction limits and to the next interchange on freeway. In cases where next intersection is close (e.g., Outer Road), consider the [https://epg.modot.org/index.php/940.3_Clearance_of_Functional_Areas_of_Interchanges functional area of the interchange].
:• '''Arterials –''' one major intersection on either end of the project. Include minor streets at least up to next major upstream intersection or end of street, to the extent possible. 1000 feet is desirable for queue evaluation, even if space may not be physically available.

=====905.3.5.3.2.2.2 Global Network Parameters=====
Unless otherwise requested during the scoping process, all VISSIM parameters should be coded using U.S. customary units (ft and mph). The simulation resolution typically should be set to ten time steps per simulation second. Any other value should be documented in the Methods and Assumptions Memo. Best practices recommend that modelers use an aerial image as the basis for their model. Recent versions of VISSIM allow modelers to take advantage of Bing Map aerials and OpenStreetMap schematic map sources that are scalable. However, modelers using imagery from external sources should take care to scale their imagery appropriately by using VISSIM to assign a base coordinate system and sizing to their images.

It is recommended to utilize MoDOT’s customized base VISSIM file for proper default initial parameter set up. This file should be used for all VISSIM projects unless approved by MoDOT and included in a Methodology and Assumptions (M&A) report.

=====905.3.5.3.2.2.3 Vehicle Fleet Setup=====
In the Traffic Analysis Toolbox, Volume III, the FHWA recommends that analysts should “attempt to obtain the vehicle fleet data (vehicle mix dimensions, and performance) from the local state DOT or air quality management agency.” It is best to use data from the specific project area to define the vehicle fleet. If this is not available, however, MoDOT has developed a vehicle fleet that should be used. This vehicle fleet is already coded into MoDOT’s customized base VISSIM file and can be viewed by clicking on Base Data -> Distributions -> 2D/3D Model.

The fleet coded into the model has associated 3D vehicle model files with defined lengths/widths and truck/trailer combinations for those semi-tractor trailer types. If the analyst receives warnings that certain 3D model files cannot be found when opening the base VISSIM file, then the missing files must be copied into the location on the user’s hard drive shown in the warning message. [http://cgi.ptvgroup.com/cgi-bin/en/traffic/vissim_download.pl 3D models provided by PTV Group] (including those needed for MoDOT’s default fleet) can be downloaded for free.

=====905.3.5.3.2.2.4 Scenario Manager=====
The scenario manager allows the user to develop a base model that can be used to apply one or more modifications to create various scenarios. Modifications can be turned on and off to create different combinations of scenarios. These scenarios may have different volumes or network modifications that can be directly compared to each other. This feature is available from VISSIM Version 8.0 and later. Use of the scenario manager is completely optional. Should modelers choose to use the scenario manager, this choice should be discussed during the scoping process and details regarding how the scenario manager was used should be included in the final project report.

=====905.3.5.3.2.2.5 Network Link Coding=====
VISSIM modeling begins by establishing links, then joining those links with connectors. Links are representations of roadway networks that reflect the traffic flow and geometry of each road segment. Connectors are used to join two parts of a single link or two parts of two different links. In addition to joining links, connectors also have characteristics that determine driver behavior in the model. For this reason, it is important to be aware of how many connectors are being used in a model and to eliminate unnecessary connectors or to shorten lengthy ones.

'''Freeway Merge, Diverge, and Weave Coding'''

During scoping, it should be determined if HCM methodology for analyzing freeway segments will be strictly followed. If LOS is the main MOE used, then this is recommended, and the following guidance applies:
:• Typical freeway merges and diverges should be coded with a length of 1,500 ft. from the painted gore point.
:• Weaves may be coded as a single link between ramp gores as long as roadway attributes do not change. The first links coded on either end of the weave should be no longer than 500 feet.

If other MOEs (e.g., travel time, speed, etc.) are primarily used, then the above distances are not as crucial. Regardless of MOEs, the following modeling practices are recommended:
:• Any parallel acceleration or deceleration lane should be coded for the full length of the parallel distance and half the length of the taper unless a different distance is needed for calibration purposes.
:• No parallel distance should be coded for tapered entrances and exits. Often no conflict areas or priority rules are coded, even at a merge. The model may show vehicles overlapping each other, but they then adjust their spacing for the merge to occur. Lane taper links can be coded for visual completeness but should not be connected to links that actively carry traffic or need to be closed to all vehicle classes.
:• Unless other distances are needed for calibration, connectors to off-ramps should be coded with a lane change distance (LCD) of 5280 ft. or with measured distances to the locations of upstream signage that indicates the upcoming off-ramp. LCD is discussed in more detail in [[#905.3.5.3.2.3.3 Calibration Parameters|EPG 905.3.5.3.2.3.3 Calibration Parameters]].
:• Mainline connectors at the end of acceleration and deceleration lanes should be coded with a lane change distance that covers the full distance of the acceleration/deceleration lane.
:• Mainline connectors at the end of weaves should be coded with a lane change distance that covers the full distance of the weave.
:• Grade information (especially that over two percent) should be included from field observation/measurement or external sources (traffic signal plans, roadway design plans, aerial imagery/LIDAR sources etc.).

'''Surface Streets and Intersections'''

When coding intersections, turn lanes can be coded on the same link as the through lanes or as a separate link. Either method is acceptable, but different situations may call for different methods. For example, if coding turn lanes on the same link is leading to unrealistic last-minute lane changes at the stop bar, then using a separate link may be preferred. If a turn lane is shared with a through movement, then it may be best to keep everything on one single link. In the end, the approach selected should best replicate field observed driver behaviors. This may also apply to the use of connectors representing tapers between upstream links and downstream links featuring the turn lane.

Like freeway link coding, the coding of approach grades at intersections should be done consistently through a model to account for acceleration and deceleration changes and their effect on capacity. It is recommended to include grades if they are anticipated to affect the acceleration or deceleration of the vehicles, or if they are greater than two percent.

'''Roundabouts'''

There are many ways to code a roundabout in VISSIM. Several considerations include:
:• Limiting the number of links used to code the roundabout is preferred. Ideally, one circular link would be used with connectors attaching at all entry and exit points. This will help to avoid situations where connectors overlap links and mask other coding elements such that they are ignored by vehicles. Where the number of lanes varies around a roundabout, multiple links will be needed within the circle.
:• Lane changing should be prohibited within the circle when coding a multi-lane modern roundabout
:• Using desired speed decisions (DSD) helps keep speeds consistent within the roundabout, and reduced speed areas (RSA) ensure that vehicles are traveling the preferred speed at roundabout entry and exit locations where geometric deflections affect vehicle speeds. This approach to use both network elements at the roundabout to control the speed of the vehicles entering, exiting and within the roundabout allows flexibility to keep speeds in the roundabout vicinity consistent. DSDs and RSAs are discussed in more detail in [[#905.3.5.3.2.2.6 Speed Control Coding and Desired Speed Distributions|EPG 905.3.5.3.2.2.6 Speed Control Coding and Desired Speed Distributions]].
:• Conflict areas or priority rules can be used to code yielding at roundabouts, but priority rules allow for greater control of yielding, particularly for multi-lane roundabouts. Additional information on conflict areas and priority rules are found in [[#905.3.5.3.2.2.7 Control Coding|EPG 905.3.5.3.2.2.7 Control Coding]].

'''Pedestrian and Bicycle Links'''

The inclusion of bicycles and pedestrians in the model should be discussed during scoping. Generally, they should be included if they have a measurable impact on operations or if they are needed for visualization purposes. The level of effort used for modeling bikes and peds should be in line with the level of impact. Larger cities may have stricter requirements for bicycle and pedestrian analysis.

=====905.3.5.3.2.2.6 Speed Control Coding and Desired Speed Distributions=====
Speed control coding dictates the speeds with which vehicles traverse different links and navigate certain movements. Desired Speed Decisions (DSD) and Reduced Speed Areas (RSA) are both controlled by Desired Speed Distributions. These distributions provide a range of potential speeds that can be assigned to individual vehicle classes during simulation. Desired Speed Distributions are particularly important parameters because they influence link capacity and achievable travel times. VISSIM produces a range of default speed distributions in a new .inpx file that “generally” could be considered to correspond to some posted facility speed limits, but for consistency, establishment of DSD’s based on the criteria described below are recommended.

Best practices recommend generating Desired Speed Distributions from existing field data for existing conditions models and for future models with the same geometry as existing conditions. For future models of arterials, using a linear distribution ranging +/- 5 mph from the posted speed limit is reasonable. For future models of freeways, using a linear distribution ranging from 3 mph below the posted speed limit to 10 mph above the speed limit is reasonable. In addition, a default distribution with using the posted speed as the 85th percentile speed in a distribution curve can also produce reasonable variation in traffic speed for any model scenario. Curve advisory speeds for loop ramps (use 25 mph as default) and for diamond ramps (35 mph) can also be applied.

Particularly for uninterrupted freeway facilities, free flow speed distributions are useful for calibration purposes to produce more realistic conditions. Speed data may be obtained by point speed data collection at/near network entry locations where flow interruptions or geometric conditions (grades/sight distance etc.) are at a minimum, or from third party big data sets (e.g., NPMRDS, INRIX, RITIS) that can produce appropriate individual speed estimates for network segments from which a distribution can be obtained. Similar data could be collected for interrupted facilities, though collection of truly free-flowing speeds may be more difficult due to traffic control devices and generally more turbulent conditions along an arterial corridor.

'''Desired Speed Decisions'''

As drivers enter the network during a simulation, they are assigned a desired speed from the Desired Speed Distribution that is associated with their vehicle class. Unless they are hindered by other vehicles or network objects, such as signal controls, drivers will travel at the desired speed they were assigned at entry in the Vehicle Compositions for each Vehicle Input. Placing a Desired Speed Decision in the network creates a place where a driver’s desired speed is updated and they are reassigned a speed from the Desired Speed Distribution associated with their vehicle class. This process will be repeated each time a driver encounters a Desired Speed Decision.

When approaching a Desired Speed Decision, a driver will not accelerate or decelerate in anticipation of a change in their Desired Speed. A vehicle’s speed will begin to change once it has passed through the Desired Speed Decision and not before. For this reason, it is important that modelers account for the amount of time it will take for a driver to accelerate or decelerate to their new Desired Speed.

In general, desired speed distributions from MoDOT’s base VISSIM model can be selected based on the posted speed limit. During the calibration process, it may be necessary to provide different DSDs at a desired speed decision point if field data or observation indicate that, for example, trucks operate at a more conservative speed than cars along a particular link. Care should be used in applying this method to all situations, as the performance of cars and trucks may also be affected by the presence of grades.

'''Reduced Speed Areas'''

Vehicles in a VISSIM network will not automatically adjust their speed for turning movements as drivers in the real world normally do. For this reason, Reduced Speed Areas must be defined for areas where turning movements take place.

Best practices recommend that Reduced Speed Areas for right turns and U-turns use a linear distribution with a range of 7.5 mph to 15.5 mph. Similarly, best practices recommend that Reduced Speed Areas for left turns use a linear distribution with a range of 12.4 mph to 18.6 mph. Modelers should note that these distributions are coded into the base VISSIM model and represent a reasonable baseline, but they can be adjusted during the calibration process if need be. Reduced speed areas may also be placed in areas of a network where significant horizontal geometry changes occur that would impact the normal desired vehicular speed. For a more precise estimate of speeds around a curve, refer to AASHTO Green Book Table 3-13b.

In the model calibration process, if bottlenecks/congestion occurs beyond the area of a modeled network, reduced speed areas may be used at network exit points to emulate the extent and duration of the off-model congestion. Reduced speed areas have the ability on a per-lane bases to change the nature of the reduced speed and the time period for which it might be applied. While <u>this is not a preferred way to model congestion and should not be used for congestion internal to the model</u>, sometimes it is necessary at the edges of the model to keep the model limits reasonable and allow models to emulate field conditions to achieve model validation thresholds.

=====905.3.5.3.2.2.7 Control Coding=====
Control coding is used to replicate real-world traffic controls such as signals, stop signs, and yield conditions (conflict areas and/or priority rules). These controls should replicate real-world conditions as closely as possible. For instance, signal timing collected should be used to code signals and conflict areas and/or priority rules should be used at all intersections to dictate realistic vehicle interactions. Conflict areas are preferred when they can adequately reflect field conditions. When coding future traffic signal timing, it is recommended that modelers use optimized signal timing. This can be done by using Synchro outputs that are then imported into VISSIM or by using another signal timing optimization software.

'''Signal Controller Settings'''

Best practices recommend the Ring Barrier Controller (RBC) method for coding traffic signals. RBC controllers can either be imported through Synchro files with optimized signal timings or can be directly coded into VISSIM using its RBC add-on module. Modelers should take care to make sure that the frequency of the RBC file matches the VISSIM time steps per second when coding signal controller settings.

Where pedestrians have a measurable impact on operations, code pedestrian signals to match corresponding through signal phase at a minimum or add pedestrian phasing specifically to RBC controller inputs. VISSIM has a separate RBC manual included with the installation for more information.

'''Unsignalized Intersections'''

Intersections which are stop controlled should be coded so that the location of stop signs is based on where drivers actually stop in the field, or if unknown, stop bar locations recorded during data collection/shown on aerial imagery. Similarly, conflict areas and priority rules should be coded at the actual locations of conflict between vehicles. Intersections which are yield controlled, like roundabouts and right turns entering a roadway, should be coded using only conflict areas and/or priority rules. Conflict areas should be applied first when coding unsignalized intersections, then priority rules can be used if real-world conditions need to be better replicated, but only one of these types of control should be active for any given conflict situation between vehicles or other modes of transportation that are modeled.

Conflict areas are automatically generated where network links and connectors overlap but are initially “inactive”. All intersections and junction areas in a network need to be assessed as to which conflict areas are needing to be activated. This is based on the likelihood of a conflict actually occurring – i.e., for a signalized intersection, no conflicting through movements should typically ever actually conflict due to the signal control of movements so these “conflict areas” do not need to be activated. Conflict areas where a through movement vehicle and right-turn movement vehicle could “overlap” due to close proximity of the links/connectors should have a “red-red” conflict area activated so vehicles will avoid entering these areas if a vehicle is stopped and present in either direction.

=====905.3.5.3.2.2.8 Vehicle Types/Inputs/Compositions=====
A <u>vehicle type</u> allows the formation of a group of vehicles with the same technical driving characteristics. The vehicle type data is included in emission calculations. Vissim has the following default vehicle types:
{| style="margin: 1em auto 1em auto"
|-
|• Car||width="15"| ||• Man
|-
|• HGV|| ||• Woman
|-
|• Bus|| ||• Bike
|-
|• Tram||
|}

Based on these vehicle types, it is possible to further define specialized vehicle types such as a trailer truck, articulated truck, standard bus, articulated bus.

If vehicles in a vehicle category have different speed or acceleration behavior, define each vehicle type separately.

If vehicles of one type only differ in their shape, length or width, they may be distinguished by 2D/3D model distribution or color distribution and still would be managed under the same vehicle type. For example, the “car” vehicle type represents vehicle models that differ in length but have a similar driving behavior. This is why they can be defined under a single vehicle type, using 2D/3D model distribution for different types of “car” vehicles.

Vehicle types can be grouped into <u>vehicle classes</u>. A vehicle class may contain any number of vehicle types. Vehicle classes provide the basis for speed data, evaluations, path selection behavior and other network objects. Per default, a vehicle class contains a vehicle type of the same name. You may assign a vehicle type to several vehicle classes. A vehicle class is, for example, used to obtain data for specific vehicle types or to recognize and distinguish them based on their color during simulation.

Vehicles with different technical driving properties must belong to different vehicle types. Group vehicle types to a vehicle class in the following cases:
:• If multiple vehicle types share the same properties such as speed distribution,
:• To collect aggregated data on all vehicles collectively.

Best practices recommend that <u>vehicle inputs</u> be coded in 15-minute demand increments. In some situations where traffic volumes are consistent over longer time periods, hour long demand increments can be used. If there are significant differences in the vehicular fleet characteristics between input locations, then the fleet mix specific to each entry location should be specified. In the case of freeway models, a global estimate of heavy vehicles in the traffic stream can be generated from project-specific classification counts / project-level traffic forecast data or a regional travel demand model if no classification count or forecast information is available. In the case of modeling of new facilities in a future scenario, forecast or regional travel demand model information would be needed to properly assess the future vehicle mix on facilities that do not exist in the base model.

All vehicle input locations to the model require information on vehicle compositions which need to be coded separately. The vehicle compositions, depending on the level of detail needed and information available for each entry link, can be modified at a global level, roadway functional class level, or individual link level, as noted above. Vehicle compositions include the vehicle class differentiation, assumed speed distributions, and relative proportions of each vehicle type.

=====905.3.5.3.2.2.9 Vehicle Routing=====
Similar to vehicle inputs, vehicle routes should be coded in 15-minute demand increments if possible. Hour-long demand and routing increments are acceptable in cases where traffic volumes are consistent throughout the time period. There are three methods for coding vehicle routing, each of which has been briefly described below:
:• '''Origin-Destination Static Routing (Preferred Method):''' This is the most common method of vehicle routing and applicable for most arterial and freeway networks. These routes can pass through one intersection/interchange or several, or from one end of the network to another. MoDOT’s preference is to create multiple static routes from one entry point to all destination points within a network to accept O-D information generated in a spreadsheet or similar transferrable source outside the model from traffic forecast or count data that proportionally would take each O-D pair and make appropriate traffic assignments. This allows the modeler some control over appropriate and realistic routing through a network with several paths or situations where certain O-D pairs would not be used.
:• '''Individual Static Routes from Intersection to Intersection:''' As vehicles leave one intersection, they are assigned as left turns, through movements, or right turns as they approach the next intersection. These routing assignments should be made as far upstream as possible on each link to maximize the amount of weaving and/or merging distance available to drivers. However, if intersections within a network are spaced very closely, modelers may need to route vehicles through multiple intersections to allow for adequate time for vehicles to change lanes to execute their assigned turning movement. This can be achieved using the Combine Routes feature of VISSIM.
:• '''Origin-Destination (O-D) Based Dynamic Traffic Assignment (DTA) Routing:''' - In some cases where multiple paths are available in a grid network, or network with paralleling route options, automated O-D routing in VISSIM can be done by using VISUM to macroscopically assign the O-D matrix to the network and then by using VISSIM’s Dynamic Traffic assignment to generate the actual routes. This is a complex, iterative process that should be used in limited situations with a full knowledge of the methodology by which VISSIM integrates O-D matrix flow taken from VISUM (or other travel demand model software packages) and is modified to properly assign traffic flows to match existing traffic patterns and avoid unrealistic paths through the model network. Approval will be needed by MoDOT prior to using O-D based DTA for traffic assignment and documentation of processes and model changes necessary to achieve desired DTA goals will be necessary in the Methodology and Assumptions and Model Calibration reports.

=====905.3.5.3.2.2.10 Driver Behavior=====
Vehicle interactions in VISSIM are guided by the Wiedemann 1974 and 1999 car-following models, in addition to several proprietary lane changing models. Users can alter these lane changing models by adjusting the parameters located in driver behavior containers. These driver behavior containers are assigned to links within the network and dictate how vehicles travel and interact along the link. VISSIM provides eight default driver behavior containers each of which is briefly described below in Table 905.3.5.3.2.2.10.

<center>
======Table 905.3.5.3.2.2.10, Default Driver Behavior Container======
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE"|Container Name !! style="background:#BEBEBE"| Description/Purpose
|-
|align="center"|Urban (motorized)||Based on the Wiedemann 1974 car-following model, therefore, is '''recommended for use when modeling arterials.''' This container is typically the default for urban streets and arterials.
|-
|align="center" width="300"|Right-side rule (motorized)||width="600"|Based on the Wiedemann 1999 car-following model, therefore recommended for use when modeling freeways. This container dictates that vehicles only use the left lane to pass. This practice is common in Europe, but not necessarily in the United States.
|-
|align="center"|Freeway (free lane section)||Based on the Wiedemann 1999 car-following model, therefore, is '''recommended for use when modeling freeways.''' This container is typically the default for freeways.
|-
|align="center"|Footpath (no interaction)||Used to control pedestrian movements on walkways and crosswalks because it does not monitor the interaction between entities modeled on these links.
|-
|align="center"|Cycle-Track (free overtaking)||Used to control bicycle movements on cycle tracks. Based on the Wiedemann 1999 car-following model but incorporates updated parameters that mimic cyclist behavior more realistically.
|-
|align="center"|AV_cautious (CoEXist)||Based on the Wiedemann 1999 car-following model. Includes updated parameters to reflect cautious behavior of an Automated Vehicle as determined by the CoEXist research project.
|-
|align="center"|AV_normal (CoEXist)||Based on the Wiedemann 1999 car-following model. Includes updated parameters to reflect normal behavior of an Automated Vehicle as determined by the CoEXist research project.
|-
|align="center"|AV_allknowing (CoEXist)||Based on the Wiedemann 1999 car-following model. Includes updated parameters to reflect all-knowing, or fully connected, behavior of an Automated Vehicle as determined by the CoEXist research project.
|}
</center>

=====905.3.5.3.2.2.11 Coding of Other Modes=====
There may be a desire in some models to code other transportation modes such as pedestrians, bicycles, buses, trains, etc. When modeling transit stops (especially with buses), make sure to consider the possibility that a bus may skip the stop. If creating dwell time distributions for bus stops, note that dwell time values of zero or less will result in the bus skipping the stop if skipping is allowed. Knowing what percentage of the time the bus skips the stop may impact how the dwell time distribution is coded.
=====905.3.5.3.2.2.12 Using Lists in VISSIM=====
Within VISSIM a list can be generated for most model elements. Many parameters can be selected to be included as columns in the list. The lists can be very beneficial for making similar changes to many elements quickly. The list itself can be copied to a Microsoft Excel file, manipulated using the full functionality of Excel, and then imported back into VISSIM. Lists can also be used to organize and filter data within the model.

====905.3.5.3.2.3 Error Correction, Calibration and Validation====
Once base model development is complete, it is important to run the model and check the model for errors and to correct those errors. Then, possibly the most important step of the process, is calibration of the existing model. Calibration give confidence that the model is replicating real world conditions reasonably well. The calibrated model and the settings used to calibrate the model is carried forward and mimicked in the alternatives’ testing. EPG 905.3.5.3.2.3 describes the process of initial model run set-up, error detection and rectification, and detailed model calibration once a model has been checked for basic coding errors.

=====905.3.5.3.2.3.1 Initial Simulation Runs=====

'''Determining the Seeding Period'''

A seeding period, the amount of time required for a network to reach equilibrium and/or saturated conditions, should be identified that is the longest of the following four criteria:
:1. A minimum of 15 minutes.
:2. The number of vehicles in the network levels off. Note that in a highly congested network the rate of increase may slow down, but the number of vehicles will continue to increase throughout the simulation.
:3. Equal to or greater than twice the estimated free flow travel time from one end of the network to the other.
:4. Vehicle queue lengths in the model at the end of the period are similar to real-world observations at that time of day.

'''Calculating Required Number of Simulation Runs'''

MoDOT’s preference for the number of simulation runs to provide adequate statistical validity is to start with a recommended number of 20 runs. Depending on a model’s size and complexity or for other reasons discussed and agreed upon on the project scoping process, this number may be reduced under 20 to a minimum of 10 if justified using the FHWA’s guidance on calculating the required number of simulation runs that is outlined in ''Traffic Analysis Toolbox Volume III: Guidelines for Applying Traffic Microsimulation Modeling Software - 2019 Update to the 2004 Version''. FHWA’s methodology uses a standard statistical t-test to determine the number of simulation runs required to ensure a 95<sup>th</sup> percentile confidence level with a 10% tolerance. The t-test is executed using the following equation:

:::::<math> N = \frac{Z^2S^2}{E^2}</math> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Simulation Runs Equation

:Where:
::N = Number of simulation runs
::Z = z-score (1.96 for the 95<sup>th</sup> percentile)
::S = Standard deviation of the sample
::E = Tolerable error in terms of the sample mean

In this methodology, the initial sample consists of the values of a primary MOE (such as network speeds, travel times, overall delay or throughput) returned by the first N runs of the simulation. Use of generalized network-level statistics for the sample is preferred and more than one MOE statistic should be utilized in the assessment of minimum run size. The MOE producing the largest number of runs should be considered to be used as a conservative basis for determining the minimum number of calibration runs. The sample standard deviation (S) is used directly in the equation shown above, while the sample mean is used to calculate the tolerable error (E). E is calculated by multiplying the sample mean by the error tolerance, which is typically a total range of 10% which equates to +/- 5 percent from the sample mean. A different tolerance or percentile confidence interval could be used if agreed upon by the project team.
If the first calculation of the number of required simulation runs (N) is less than or equal to 10, then 10 model runs is statistically acceptable. If the first calculation of N is greater than 10, modelers should run the number of simulations returned by the equation and repeat the calculation until the number of simulation runs returned by the equation is less than or equal to the number of runs used to generate the sample.

''Number of Required Runs - Example''

Travel speed has been chosen as the primary MOE for an analysis. After 10 initial runs, the sample of speeds has a mean of 32.5 mph and a standard deviation of 6.5 mph. Assuming a 95% confidence level and 10% tolerance error, Z is 1.96 and E is 3.25 mph. Using the Simulation Runs Equation, N is calculated to be 15.37, or 16 runs. This tells the modeler that using only 10 simulation runs would be inadequate. Instead, the modeler should recalculate the required number of simulation runs using a sample size of 16. The modeler should then iterate through this process until the value of N they calculate is less than or equal to the size of the sample being used to calculate N.

'''Random Number Seeds and Intervals'''

Once the appropriate number of runs is determined, a consistent hierarchy should be established for the random number seeds and interval to be set for the calibration process. It is suggested that a range of numbers be consistently applied for all models of one time period both in the calibration process and for future scenario testing. An initial random seed number can be set and then an interval of 10 or greater can be established for the total number of runs required. This can be kept constant for a different time period or a new initial number and range for that time period can be established, which again would be kept constant for future scenarios of that time period. For example, in Table 905.3.5.3.2.3.1:
<center>
======Table 905.3.5.3.2.3.1, Example of Random Seeds and Increments======
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
!style="background:#BEBEBE" rowspan="2"|Model!! style="background:#BEBEBE" rowspan="2"| Initial Random Seed !! style="background:#BEBEBE" rowspan="2"| Increment !! style="background:#BEBEBE" colspan="9"|Run
|-
! style="background:#BEBEBE"|2 !! style="background:#BEBEBE"|3 !! style="background:#BEBEBE"|4 !! style="background:#BEBEBE"|5 !! style="background:#BEBEBE"|6 !! style="background:#BEBEBE"|7 !! style="background:#BEBEBE"|8 !! style="background:#BEBEBE"|9 !! style="background:#BEBEBE"|10
|-
|AM Peak||12||10||22||32||42||52||62||72||82||92||102
|-
|PM Peak||23||11||34||45||56||67||78||89||100||111||122
|}
</center>

=====905.3.5.3.2.3.2 Error Correction Process=====
Modelers should note that MoDOT has made a reviewer’s checklist available for those reviewing VISSIM base models. The best practices outlined in EPG 905.3.5.3.2.3.2 should be used in conjunction with the reviewer’s checklist to carry out the error checking and debugging processes. Ideally this review will be done by a modeler who did not have a hand in the majority of the coding process but is well versed in the development and use of the VISSIM software, along with EPG 905.3.

'''Input Review/Verification'''

After network coding has been completed, the review process should begin with a check of all network inputs. Any deviations from what was previously documented in the project [[media:905.3.2.5 TIA Methods and Assumptions Report.docx|TIA Methods and Assumptions Report]] or [[media:905.3.5.3.2.3.2 Data Collection Summary.docx|Data Collection Summary]] should be noted in the [[media:905.3.5.2.3.2 Calibration Report.docx|Calibration Report]]. Refer to MoDOT’s [[media:905.3.5.6 VISSIM Checklist.docx|VISSIM Reviewer’s Checklist]] for a full list of inputs that should be checked.

'''Animation Checking'''

<u>Watching the animation shown in the VISSIM interface while a simulation is running is an effective and necessary way to quickly spot errors.</u> The reviewer should observe the animation for the full seeding period and simulation time, paying special attention to points of congestion to verify that driver behavior is realistic. If the reviewer notices unrealistic behavior, the following issues may be to blame:

:'''Data coding errors:''' The reviewer should check for minor data coding errors that might be causing the model to produce an inaccurate representation of travel behavior.
:'''Route assignment errors:''' If the unrealistic behavior the model produces involves an excessive number of vehicles traveling to the end of a link and not attempting a lane change to continue the route, enter a turn lane, or some similar situation, the reviewer should check for errors in route assignment, as the route the vehicles may be assigned to may be incomplete or missing a valid sequence of links and connectors
:'''Error in expectations:''' Before continuing, review vehicle behavior at the location and time period in question to ensure that the reviewer has an accurate understanding of actual driver behavior in the field. Further inspection of field conditions may reveal causes for unusual vehicle behavior. If this is the case, the causes should be coded into the model to ensure the model replicates realistic behavior.

Discrepancies between model results and field conditions may also arise because of unique events that occur in the field that have not been accounted for when coding the model. Some of these unique events include the following:
:• Irregular vehicle operations (e.g., drivers using shoulders as turning or travel lanes, etc.)
:• Previously unidentified points of ingress or egress
:• Complex driver behavior, such as the interactions in a two-way left turn lane (TWLTL)
:• Average travel speeds that exceed posted or legal speeds (the average speed measured in the field should be used in the calibration process)
:• Turn bays that cannot be fully utilized because they are blocked by through traffic
:• Localized problems that can result in a system-wide impact – oversaturated intersections where vehicles block critical movements eventually locking up an entire network
:• Stopped vehicles in flowing traffic
:• Frequent lane changes or lane changes in unrealistic locations
:• Vehicles turning at inappropriate times or locations
:• Vehicles requiring long or accepting short, risky gaps
:• Signal timing and coordination errors
:• Large number of vehicles routed on minor streets.

'''Review VISSIM Error Log/Files'''

At the end of every simulation run, VISSIM provides an error log that provides the user with the time and location of model errors. The location is specified by the line number in the input file or with the link number, and the time is specified by the time step in the simulation. Modelers should review each entry in the error file to ensure that the errors are not impacting the model’s results. There are three types of error messages that represent potentially significant issues:
:• An entry link that did not generate all vehicles (congestion spillback off the network)
:• A vehicle left its route because the distance between the routing decision and the first connector on its path was too short
:• A vehicle was removed from the network because it had reached the maximum lane change waiting time (time before diffusion).

These errors are usually associated with areas of congestion in the model. Modelers should take care to make sure that these areas are associated with areas of congestion in the field and not caused by coding errors. In general, adjustments to lane change behaviors, driver behavior changes applied to select critical links, or geometric changes through adjusting distances of links, connectors and junction points may fix these issues.

In large model networks with extended periods and/or locations subject to oversaturated conditions, it may not be feasible to correct every single instance of vehicles being removed from the network because of diffusion. In the model calibration report, some mention of this occurrence should be made and a report of the overall percentage of vehicles in the network being removed due to diffusion (less than 0.5 percent would be a good general rule of thumb).

'''Common Coding Errors'''

If the source of a modeling error still cannot be found after reviewing the model’s inputs and the error files VISSIM provides, modelers may find it useful to consult the below list of common coding errors. Otherwise, this list may be useful for modelers to consult before they begin coding to make themselves aware of common pitfalls.
:• '''Signal timing/signal head coding:''' Coding signal timing and signal heads can be difficult because signal timing is usually coded in an *.RBC file, then referenced into a *.inpx file. Before referencing the signal timing code into VISSIM, there is not a good way to visualize what is been coded. To help alleviate this issue, VISSIM includes a test function that gives users the chance to watch signal heads change color in the network according to the referenced RBC file. Although this is a helpful tool when reviewing signal coding, it is sometimes more effective to watch the signals operate in the simulation and use the Evaluation->Window->Signal Times Table feature. Modelers should take care to review RBC files that are imported from older versions of VISSIM or from Synchro to ensure the transfer of signal timing parameter data is consistent.
:•''' Vehicles driving over red signal heads:''' This may occur if a connecter has been coded over a signal head that is coded on a link. In this case, the simulated vehicles will be considered as being on the connector rather than the link and therefore will not respond to the status of the signal head.
:• '''Ensure adequate Conflict Areas are coded:''' Modelers should take care to observe whether simulated vehicles are colliding where links overlap. If this occurs, the affected area will likely require an additional Conflict Area or Priority Rules so that vehicles yield to each other appropriately.
:• '''Check that Lane Change Distances are coded correctly:''' Using a Lane Change Distance which is too short is a common issue, especially when coding freeways. This error usually results in the formation of long, unrealistic queues at decision points in the network (e.g., an off-ramp on a freeway). [[#905.3.5.3.2.2.12 Using Lists in VISSIM|EPG 905.3.5.3.2.2.12 Using Lists in VISSIM]] includes a discussion of how to use lists to easily modify the lane change distances of many connectors at once.
:• '''Check that Desired Speed Decisions have been coded correctly:''' Because Desired Speed Decisions dictate the speed at which vehicles travel within the network, forgetting to code speed decisions or coding them incorrectly will result in simulated vehicles moving at significantly different speeds on the same facility. Modelers can set graphic parameters to color-code vehicles by speed to help look for these abnormalities during animation review and should address speed decisions accordingly.
:• '''Check that Reduced Speed Areas are coded at all intersections for U-turn, right-turn and left-turn connectors:''' Use of Reduced Speed Areas ensures that turning vehicles travel at a reasonable speed as they turn.
:• '''Check that correct vehicle types are coded on correct facilities:''' Modelers should note whether the mix of vehicles on a facility is appropriate during the animation review process. For instance, while VISSIM can simulate pedestrians on a freeway, this would likely never be done intentionally. Vehicle mix issues can also be less obvious. In particular, the percentage of truck traffic in a vehicle mix should be carefully evaluated during the review process to ensure it aligns with typical conditions. Color-coding vehicles by vehicle type and/or reviewing model outputs by vehicle type can help with this check.
:• '''Ensure entry links are sufficiently long for downstream routing decisions and to contain queues:''' If entry links are not coded with sufficient length, vehicles will not have the space they need to make necessary lane changes when entering the network. If a model produces significant congestion at the beginning of a network, entry links upstream may need to be made longer. Where possible, links should be long enough to allow all vehicles to enter the network and prevent warnings that vehicles are remaining unserved into the network at the input locations. Additional link modifications may be necessary to load traffic into the actual study area network where entry links are not part of the area where link evaluations are made. In cases of short minor street/driveway entry links, similar adjustments can be made, with a possibility in all cases of creating links that are invisible (to still allow accurate visualization of the model and replication of actual field conditions).

=====905.3.5.3.2.3.3 Calibration Parameters=====
Calibration parameters are the parameters modelers adjust to finely tune a VISSIM model to real world conditions. EPG 905.3.5.3.2.3.3 provides brief descriptions of how to apply commonly used calibration parameters.

'''Lane Change Distance Parameters'''

There are several link connector parameters related to how lane changes are made within a network that can be adjusted to calibrate a model. The first is lane change distance (LCD), which dictates how early a vehicle in the model will begin to make a lane change before reaching a decision point, such as a turning movement or exiting a freeway. The default value for this parameter in VISSIM is 656.2 feet (200 meters), however, this distance is generally too short to be considered realistic in congested arterials and most freeway networks. To make sure that vehicles make lane changes at the proper times on freeways and arterials, the default LCD may need to be lengthened and initial model development suggestions are found in [[#905.3.5.3.2.2.5 Network Link Coding|EPG 905.3.5.3.2.2.5 Network Link Coding]]. Additional calibration for lane change distances may need to include lengthening LCDs beyond initial suggestions at major freeway system interchanges or actually reducing LCDs in some diverge situations where field observations indicate, due to congested conditions, that vehicles make late lane changes or do not react until the very end of a freeway lane drop.

LCD can be modified on a “per lane” basis, so the distance entered will be added to its singular lane distance for each freeway or arterial lane that is adjacent to the connector “exit” lane. The resulting effect is that vehicles in lanes furthest from the connector will begin lane positioning further upstream than lanes adjacent to the connector. Care should be taken to observe the effects on traffic lane-changing movements upstream of a critical network weaving or diverge area if the “per lane” option is used versus a singular value for LCD that would apply to all lanes upstream.

Emergency stop distance (ESD) is a second parameter that may require adjustment to match conditions on arterials and freeways more realistically. Increasing the ESD would help to ensure that the vehicles in the model are stopping to wait for a lane change before reaching the decision point. This can occur at a diverging off-ramp downstream of congested weaving section. Separating the ESD for the two weaving maneuvers by 100 feet (or possibly more) reduces the potentially unrealistic vehicle behavior that two vehicles would make emergency stops at the same location to force their intended maneuvers.
While altering LCD and ESD can help during calibration, modelers should consider how lengthening these distances may have network-wide impacts and refine their parameter adjustments accordingly. For example, an LCD that is too long can have unintended consequences of vehicles positioning for a decision too far upstream, resulting in poor lane utilization. An ESD that is too long could cause vehicles to stop in the middle of the network for seemingly no reason.

'''Speed Distributions'''

As discussed in [[#905.3.5.3.2.2.6 Speed Control Coding and Desired Speed Distributions|EPG 905.3.5.3.2.2.6 Speed Control Coding and Desired Speed Distributions]], where field speed data is not available, speed decisions are coded into a model according to posted speeds and reduced speed areas are coded where drivers would reasonably travel at lower speeds (i.e., significant curves, turning movements, etc.). Both speed decisions and reduced speed areas are defined by speed distributions.

Best practice dictates that speed distributions portraying posted speed limits be generated so that 85% of vehicles travel at or above the posted speed limit and the maximum speed of any vehicles in the network is 10 mph above the speed limit. However, modelers may see a need to stray from these best practices slightly during calibration. It is generally acknowledged that drivers will exceed posted speed limits in free-flow conditions.

'''Driving Behavior'''

In VISSIM, driver behavior is dictated by car following models and lane change models. During initial model development or later on for calibration purposes, parameters within these models can be adjusted to more accurately reflect real-world driver behavior in the area being modeled. The following guidance provides brief descriptions of these models and the parameters they contain which may be modified.

:'''1. Car Following Models'''

:There are two car following models available in VISSIM: the Wiedemann 99 Model and the Wiedemann 74 Model. Best practices recommend that the Wiedemann 99 Model be used for freeway traffic and the Wiedemann 74 Model be used for arterial/urban traffic. Both models have a parameter for Number of Observed Vehicles that could be increased to up to ten to better account for the interaction with many surrounding vehicles.

:There are 10 parameters in the Wiedemann 99 Model, and three of the most influential parameters are defined below. These definitions are followed by Table 905.3.5.3.2.3.3.1 which specifies recommended starting default values and suggested ranges for all 10 parameters.

:'''CC0 (standstill distance):''' rear-bumper to front-bumper distance between stopped cars
:'''CC1 (headway time):''' distance (in seconds) a following driver wishes to keep between their vehicle and the vehicle in front of them
:'''CC2 (following variation):''' a measure of how much more distance than the desired safety distance before the driver intentionally moves closer to the vehicle in front of them.

<center>
======Table 905.3.5.3.2.3.3.1, Recommended Wiedemann 99 Car Following Parameters======
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
!style="background:#BEBEBE" rowspan="2" colspan="2"|Parameter!! style="background:#BEBEBE" rowspan="2"| Default!! style="background:#BEBEBE" rowspan="2"| Unit!! style="background:#BEBEBE" colspan="2"|Suggested Range !! style="background:#BEBEBE" rowspan="2"|Capacity Effect
|-
! style="background:#BEBEBE"| Basic Segment!! style="background:#BEBEBE"|Merge/Diverge<br/>& Weaving
|-
|width="80"|CC0||align="left"|Standstill distance||4.92||ft||4.5 – 5.5||> 4.92||Higher value = lower capacity
|-
|CC1||align="left"|Headway time||0.90||s||0.70 – 3.00||0.90 – 3.00||Higher value = lower capacity
|-
|CC2||align="left"|"Following" variation||13.12||ft||6.56 – 22.97||13.12 – 39.37||Higher value = lower capacity
|-
|CC3||align="left"|Threshold for entering "following"||-8|| ||colspan="2"|Use default||
|-
|CC4||align="left"|Negative "following" threshold||-0.35|| ||colspan="2"|Use default||
|-
|CC5||align="left"|Positive "following" threshold||0.35|| ||colspan="2"|Use default||
|-
|CC6||align="left"|Speed dependency of oscillation||11.44|| ||colspan="2"|Use default||
|-
|CC7||align="left"|Oscillation acceleration||0.82||ft/s<sup>2</sup> ||colspan="2"|Use default||
|-
|CC8||align="left"|Standstill acceleration||11.48||ft/s<sup>2</sup>||colspan="2"|Use default||
|-
|CC9||align="left"|Acceleration at 50 mph||4.92||ft/s<sup>2</sup>||colspan="2"|Use default||
|}
</center>

:When using the Wiedemann 74 Model for analysis of arterial and/or urban traffic conditions, there are three parameters to consider: average standstill distance, additive part of safety distance, and multiple part of safety distance. Average standstill corresponds to the CC0 parameter used in the Wiedemann 99 Model and can be subject to calibration as shown in the table above, while the other two parameters dictate the target desired safety distance which has a direct impact on the ultimate saturation flow rate of the network. In general, using MoDOT’s base VISSIM model’s default parameters is adequate most of the time for undersaturated conditions as it was developed to emulate typical driver behaviors observed in Missouri. If conditions are known to be oversaturated in the calibration of existing models, it is likely that additional driver behaviors may need to be created to address areas of a freeway/arterial network that experience congestion. If these parameters need to be adjusted during calibration, modelers should note that increasing the additive part of safety distance and the multiple part of safety distance increases the desired safety distance which in turn reduces the saturation flow rate. This is highlighted in Figure 905.3.5.3.2.3.3.2 which is taken from Section 5.8.4.1 of the PTV Group VISSIM User’s Manual. The figure is representative for a particular set of vehicular attributes but generally shows the intended effects of varying the multiplicative (x-axis values) part of safety distance if it is coded as the additive part of safety distance value + 1.
<div id="Figure 905.3.5.3.2.3.3.2"></div>
[[image:905.3.5.3.2.3.3.2.jpg|center|875px|thumb|<center>'''Figure 905.3.5.3.2.3.3.2, Effect of Changes to Wiedemann 74 Model Parameters on Saturation Flow'''</center>]]

:'''2. Lane Change Models'''

:The parameters used for lane change models are the same for both freeway and arterial analysis. Similar to driver behavior model parameters, VISSIM’s default parameter values for lane change models are a good starting point in most situations. However, these parameters can also be carefully adjusted during the calibration process to help reflect real-world conditions more accurately. See Table 905.3.5.3.2.3.3.3 for a list of VISSIM’s default parameter values and suggested parameter ranges, according to MoDOT Preferences. It is important to note that the lane change model parameters are related to vehicular movements within the traffic stream in their aggressiveness and desire to change lanes to pass vehicles, merge with vehicles and laterally adjust their position. They are not the same as the lane change distance (LCD) adjustments described previously.

<center>

======Table 905.3.5.3.2.3.3.3, Lane Change Parameters ======
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:center"
|+ 
!style="background:#BEBEBE" colspan="6"|Defaults
|-
! style="background:#BEBEBE" | General Behavior<br/>Necessary Lane Change (route) !! style="background:#BEBEBE" | Free Lane Selection<br/>Own !! style="background:#BEBEBE" |Unit !! style="background:#BEBEBE" |Trailing Vehicle !! style="background:#BEBEBE" |Unit !! style="background:#BEBEBE" |Typically Adjusted?   
|-
|align="right"|Maximum deceleration:||-13.12||ft/s<sup>2</sup> ||-9.84||ft/s<sup>2</sup> ||Yes
|-
|align="right"|-1 ft/s2 per distance:||200||ft||200||ft||No
|-
|align="right"|Accepted deceleration:||-3.28||ft/s<sup>2</sup> ||-1.64||ft/s<sup>2</sup> ||No
|-
|align="right" colspan="3"|Waiting time before diffusion:||60||s||Yes
|-
|align="right" colspan="3"|Min. headway (front/rear):||1.64||ft||No
|-
|align="right" colspan="3"|To slower lane if collision time above:||0||s||No
|-
|align="right" colspan="3"|Safety distance reduction factor:||0.6|| ||Yes
|-
|align="right" colspan="3"|Maximum deceleration for cooperative braking:||-9.84||ft/s<sup>2</sup>||Yes
|-
|align="right" colspan="3"|Overtake reduced speed areas:||''Box Unchecked''|| ||No
|-
|align="right" colspan="3"|Advanced Merging:||''Box Checked''|| ||Yes
|-
|align="right" colspan="3"|Cooperative Lane Change:||''Box Unchecked''|| ||Yes
|-
|align="right" colspan="3"|Rear Correction of Lateral Position:||''Box Unchecked''|| ||No 
|-
!style="background:#BEBEBE" colspan="6"|Suggested Ranges
|-
! style="background:#BEBEBE" | General Behavior<br/>Necessary Lane Change (route) !! style="background:#BEBEBE" | Free Lane Selection<br/>Own !! style="background:#BEBEBE" |Unit !! style="background:#BEBEBE" |Trailing Vehicle !! style="background:#BEBEBE" |Unit !! style="background:#BEBEBE" |Driver Behavior Effect 
|-
|align="right"|Maximum deceleration:||-15 to -12||ft/s<sup>2</sup>||-12 to -8||ft/s<sup>2</sup>||width="200"|Higher Absolute Value = More Aggressive
|-
|align="right"|-1 ft/s<sup>2</sup> per distance:||150 to 250||ft||150 to 250||ft||Lower Value = More Aggressive
|-
|align="right"|Accepted deceleration:||-2.5 to -4.0||ft/s<sup>2</sup>||-1.5 to 2.5||ft/s<sup>2</sup>||Higher Absolute Value = More Aggressive
|-
|align="right" colspan="3"|Waiting time before diffusion:||30-60||s||Longer Duration = More Potential Unrealistic Congestion
|-
|align="right" colspan="3"|Min. headway (front/rear):||1.5 to 2.0||ft||Lower Value = More Capacity
|-
|align="right" colspan="3"|To slower lane if collision time above:||0 to 0.5||s||Lower Value = More Capacity
|-
|align="right" colspan="3"|Safety distance reduction factor:||0.25 to 1.00|| ||Lower Value = More Aggressive
|-
|align="right" colspan="3"|Maximum deceleration for cooperative braking:||-8 to -15||ft/s<sup>2</sup>||Higher Absolute Value = More Aggressive
|-
|align="right" colspan="3"|Overtake reduced speed areas:||''Leave box unchecked''|| ||rowspan="4"|If Checked – Capacity Increases
|-
|align="right" colspan="3"|Advanced Merging:||''Can Adjust''||
|-
|align="right" colspan="3"|Cooperative Lane Change:||''Can Adjust''|| 
|-
|align="right" colspan="3"|Rear Correction of Lateral Position:||''Leave Box Unchecked''|| 
|}
</center>

'''Conflict Areas and Priority Rules'''

The conflict area input dialog box is shown in Figure 905.3.5.3.2.3.3.4. In conflict areas, altering the safety distance factor (SDF) can be effective during calibration as it dictates merging behavior. The factor is multiplied by the normal desired safety distance between vehicles to determine the minimum safe distance a yielding vehicle must maintain. A smaller SDF allows for more aggressive merging behavior, while a larger SDF ensures more conservative merging behavior. Modelers should pay special attention to adjusting the SDF at merging conflict areas, such as right-turn-on-red or channelized turning movements. These adjustments may not have a large effect on throughput, but they can be used to impact delay and queueing. Overall, the degree to which adjusting SDFs affects a network depends on general network conditions like congestion levels and how the volumes of major movements compare to the volumes of minor movements at conflict areas. The default SDF for a conflict area is 1.5. A reasonable range for this value is between 1.0 and 2.0. Changes to this value in the calibration process are generally similar to adjustments made to safety distances in the Wiedemann 74 model and highlighted previously in [[#Figure 905.3.5.3.2.3.3.2|Figure 905.3.5.3.2.3.3.2]].

[[image:905.3.5.3.2.3.3.4.jpg|center|950px|thumb|<center>'''Figure 905.3.5.3.2.3.3.4, Conflict Area Dialog Box'''</center>]]

Other input values that can be adjusted to provide better realism in vehicular stopping and gap acceptance behavior is to adjust the Front Gap, Rear Gap and Additional Stop Distance parameters.
:• Both the Front Gap and Rear Gap are set to 0.5 second defaults. Increasing the gap time will cause more cautious reactions for minor and major street vehicles in the defined conflict area for crossing or merging conflicts.
:• Increasing the Additional Stop Distance from 0 feet to a higher value will cause a minor street vehicle to yield further away from the defined conflict area and thus increase the caution in behaviors at the conflict area, reducing capacity for the minor street movement.

Similar to Figure 905.3.5.3.2.3.3.4, Figure 905.3.5.3.2.3.3.5 shows the basic set up for calibration of priority rules. Three factors in the conflict marker input dialog are important in the calibration process. The gap time, clearance, and max speed inputs can be adjusted to match vehicle yielding and gap acceptance to field observed conditions. Increasing the gap time (default of 3 seconds) will lower the yielding vehicle’s aggressiveness in accepting gaps in the conflicting traffic stream. Increasing the clearance distance (default 16.4 feet) has a similar effect in keeping that defined area free of observed vehicles before the yielding vehicle accepts a gap. The maximum speed parameter is initially set at a high-speed default, meaning all observed vehicles will be considered in the yielding vehicle’s observation of gap and clearance. Lowering the maximum speed value below field travel speeds means that conflicting vehicles may not be considered by the yielding vehicle.

[[image:905.3.5.3.2.3.3.5.jpg|center|950px|thumb|<center>'''Figure 905.3.5.3.2.3.3.5, Priority Rule Dialog Box'''</center>]]

In using priority rules, it is important to code the stop line and conflict marker locations correctly and to include conflict markers for all affected traffic streams that vehicles at the stop line need to yield to – including additional lanes on a link crossing the link with the stop line. Priority rules are effective in specialized situations, such as roundabouts, “Do Not Block The Box” intersections, and situations where conflict areas are not producing accurate depictions of yielding behavior.

=====905.3.5.3.2.3.4 Calibration Targets/Model Validation=====
Calibration is a way of fine tuning a model to better replicate field conditions by iteratively adjusting several calibration parameters. A model is deemed to be sufficiently calibrated once it achieves calibration targets that are based on observed field conditions and agreed upon at the outset of a project, a process known as model validation. A few examples of such calibration targets are discussed in EPG 905.3.5.3.2.3.4 Calibration Targets/Model Validation.

'''Visual Inspection'''

Visual comparisons between a simulation and real-world traffic conditions go a long way in proving a model’s reasonableness. These inspections are important to conduct throughout the modeling process, not just during calibration. Modelers should be sure to consider multiple sources that capture real-world traffic conditions, such as observations made during data collection, photos and videos of the study area, and 3<sup>rd</sup> party congestion data.

Because these inspections are more qualitative than quantitative, modelers should use their best judgement when determining where the simulation reflects real-world traffic conditions accurately and where the simulation may require calibration. These sorts of determinations should be documented, to the extent possible, in the Calibration Report. Quantitative proof of calibration will come with the analysis of other calibration targets.

'''Volume and Origin-Destination'''

After visual inspection, showing that simulation output volumes closely match field volumes is an important step in proving that a model is calibrated. A common way of comparing a model’s estimate of volume to field counts is to compute the GEH Statistic.

The GEH Statistic is computed as follows:

::::<math>GEH = \sqrt{\frac{(E - V)^2}{(E + V)/2}}</math>

:Where:
::E = Model estimated volume
::V = Field Count

Refer to the FHWA ''Traffic Analysis Toolbox, Volume III'', Section 5.6 for more information on computing the GEH Statistic.

With regards to calibration acceptance targets for link flows and GEH statistics, ''Traffic Analysis Toolbox'' recommends the criteria shown below in Table 905.3.5.3.2.3.4. These criteria are particularly suited for freeway modeling in comparing mainline and ramp flow volumes, and also are applicable for arterial corridor volume comparisons on entry/exit links. Caution may need to be applied to use of these criteria for lower volume facilities or driveways and for application directly to intersection turning movements for arterial corridor studies. ''Traffic Analysis Toolbox'' was updated in 2019 but is not yet widely used. The study team may elect to use the newer targets in lieu of those presented here.
<center>
======Table 905.3.5.3.2.3.4, Calibration Targets for Link Flows and GEH Statistics ======
{| border="1" class="wikitable" style="margin: 1em auto 1em auto" style="text-align:left"
|+ 
!style="background:#BEBEBE" |Criteria and Measures !! style="background:#BEBEBE" | Calibration Acceptance Targets  
|-
|Individual Link Flows||
|-
|&nbsp;&nbsp;&nbsp;Within 15%, for 700 veh/h < Flow < 2700 veh/h||> 85% of cases
|-
|&nbsp;&nbsp;&nbsp;Within 100 veh/h, for Flow < 700 veh/h||> 85% of cases
|-
|&nbsp;&nbsp;&nbsp;Within 400 veh/h, for Flow > 2700 veh/h||> 85% of cases
|-
|Sum of All Link Flows||Within 5% of sum of all link counts
|-
|GEH Statistic <5 for Individual Link Flows||> 85% of cases
|-
|GEH Statistic for Sum of All Link Flows||GEH < 4 for sum of all link counts
|-
|colspan="2"|Source: FHWA Traffic Analysis Toolbox, Volume III, Section 5.6 (Table 4)
|}
</center>
<div id="Spot Speed"></div>
'''Spot Speed'''

While calibrating the number of vehicles within the network is necessary, so is calibrating the behavior of the drivers of those vehicles. Assessing driver speed (both range and average) is usually the first step in this process and is particularly important for freeway segments. Sometimes a visual check of link speeds is satisfactory, however, some projects may require a direct comparison of spot speeds for calibration.

Key calibration locations can be near model entry points where spot speeds are useful in defining/refining assumed speed profiles for traffic streams or for bottleneck/congestion locations to help in determining appropriate throughput in these areas. Spots speed verification/calibration is not needed comprehensively throughout the freeway model but is typically appropriate on select freeway mainline segments. Locations may be governed by location of existing ITS devices that may aid in the collection of spot speed data and should be discussed for inclusion in the project scoping process.

For more detailed analyses where spot speeds are widely available throughout the model, it is considered best practice for model speeds to be within +5/-5 mph of real-world spot speed data on at least 85% of all freeway links and in certain key locations where real-world speeds are available. If more precise requirements for speed calibration are deemed necessary for a project, these requirements should be outlined in a Methods and Assumptions Report at the outset of the project.

'''Travel Time'''

With regards to travel time, the FHWA ''Traffic Analysis Toolbox, Volume III'', Section 5.6 recommends that journey times within a modeled network ought to be within 15% (or 1 minute maximum, if higher) of real-world travel time runs for greater than 85% of cases. The intent is not to compare many short (one mile or less) travel time segments, but to choose longer travel times through the network that are meaningful to the project’s purpose and need. If more precise travel time calibration is deemed necessary for a project, these requirements should be outlined in a Methods and Assumptions Report at the outset of a project. It is also important to note that the standards and thresholds for spot speeds described in [[#Spot Speed|Spot Speed]] are not directly applicable to the thresholds defined for segment travel times. Both should be used in the calibration and validation process for models.

'''Queuing'''

A qualitative comparison of modeled queue lengths and queue lengths observed in the field is necessary to ensure intersections are operating properly within the model. Excessive queueing, or alternatively a lack of queueing, can be a symptom of coding errors in intersection control or vehicles demand. If the model still does not model queues accurately after coding inputs have been checked, then adjusting some calibration parameters may be required to address the issue.

In general, a qualitative comparison is sufficient when calibrating queues. However, depending on the project there may be a desire for a more detailed queue calibration at specific locations. In this case, a quantitative comparison should be detailed in a Methods and Assumptions Report and include field collected information on queue lengths, queue duration and visual comparisons to queues from collected pictures/video to model animations.

'''Lane Utilization'''

The need to calibrate lane utilization varies between projects. If collecting lane utilization data were deemed necessary during the scoping process, then lane utilization information should be extracted from the model at the same locations where data were collected in the field.

'''Transit Travel times'''

Like vehicular travel times, transit travel times can be calibrated to meet current transit schedules and field collected data, particularly if transit operations are a primary focus of a project process. Transit bus speed distributions and stop durations (including skipping probability) can be modified to reflect field data and model validation can be achieved through comparisons between field/model travel times for segments or time points along a transit route that is continuous in the VISSIM model. Model/field differences within 15 percent can generally considered to be acceptable unless more stringent criteria are discussed and agreed upon in the M&A process.

=====905.3.5.3.2.3.5 [[media:905.3.5.2.3.2 Calibration Report.docx|Calibration Report]]=====
MoDOT will require a calibration report to be submitted in conjunction with most microsimulation projects. A calibration report serves as proof that a microsimulation model has been adjusted to replicate the real-world traffic conditions within the study area. A calibration report also summarizes how the model’s ability to replicate these real-world conditions has been thoroughly validated using observed counts and measurements.

All calibration reports submitted to MoDOT should be made using MoDOT’s Calibration Report Template. Topics of discussion outlined in the template and required in all calibration reports include the following:
:• Simulation study area, analysis years, and analysis peak periods
:• Relevant data collection and preparation
:• Base model development, including model assumptions
:• Calibration procedure, including process of calibration parameter selection
:• Calibration criteria and targets
:• Summary of simulation runs and resulting parameter refinement
:• Validation results

For smaller microsimulation projects, a formal calibration report may not be required. However, the modeler may still be required to outline their calibration processes in the technical documentation they prepare for the project. If a project does not require significant calibration, and therefore does not merit a calibration report, the modeler should also explain this in their technical documentation.

====905.3.5.3.2.4 Results and Presentation====
=====905.3.5.3.2.4.1 Output Results=====
VISSIM output can be divided into two categories: output which is recommended for most projects and output which may be needed for select projects. Consultants should work with MoDOT and other stakeholders to determine what VISSIM outputs are most relevant to each unique analysis and expected to be included in a final report.

'''Recommended for Most Projects'''

MoDOT considers it best practice for modelers to include the following data in their final reports for most projects:

''Node Evaluation''

Nodes are a very efficient way to collect performance data at intersections in an orderly output, although there might be some limitations in their ability to correctly capture all queues/delays if intersections are closely spaced. Obtaining node evaluation data requires placing “nodes” throughout a network at important locations. These locations should be previously defined in a Methods and Assumptions Report and usually include study intersections, ramp terminals, and other significant points. Modelers should use the node evaluation feature in VISSIM to report the MOEs for each movement at every node and then aggregate the results for each node. MOEs to report for each node may include the following: node number, movement, number of vehicles, average delay, queue lengths, and stops.

''Travel Time''

Travel times in VISSIM are collected by creating travel time collection (TTC) segments. Upon evaluating TTC segments, VISSIM reports the average time it takes for the vehicles in the model to travel a given segment during a time interval specified by the user. TTC segments should be coded to match the segments used during data collection to conduct travel time runs in the field. Doing so allows for direct comparison of VISSIM output to real-world measurements. However, TTC segments must be coded carefully if there are several paths in the network vehicles could use to travel between the start and end of the segment. If there are multiple paths between the start and end of a segment, VISSIM will report the average time for vehicles using all available paths. It is also important to note the number of vehicles using each TTC in the model and to ensure an adequate sample size. If few vehicles are using a given TTC, it may be beneficial to break the TTC into smaller segments to increase the same sizes.

''Network Performance Evaluation''

Network performance evaluation helps to provide a general idea of how well a network is operating that can be useful for making very high-level comparisons of design alternatives, including alternatives that move access points. This evaluation produces standard MOEs including vehicle miles traveled (VMT), vehicle hours traveled (VHT), vehicle delay and stops, as well as the number of vehicles that were not able to enter the network or have to wait outside the network and the latent delay time of those vehicles. Exhibit 35 shows an example of formatted output from network evaluation data that can be easily compared to highlight advantages/disadvantages of impacts of design alternatives on the modeled study area.

[[image:905.3.5.3.2.4.1.1.jpg|1025px|center|thumb|<center>'''Figure 905.3.5.3.2.4.1.1, Network Evaluation Formatted Output Table'''</center>]]

''Link Evaluations''

Link evaluation is most commonly used when ''Highway Capacity Manual 2016'' (HCM6) Level of Service (LOS) is needed for freeway analysis. When using link evaluation, the following MOEs should be reported on a link-by-link basis:
:• Volume (Throughput)
:• Speed (spot mean speed and/or space mean speed)
:• Data collection intervals
:• Link Evaluation Segment length
:• Density

The default link evaluation segment length is short (32.8 feet, or 10 meters), so it may be beneficial to change this value for all links to a large value (99,999 feet, for example). Then links can be split to generate the desired link evaluation lengths.

Modelers should note that density calculated by VISSIM is a measured density, which does not align with the Highway Capacity Manual (HCM) definition of density. In order to obtain the HCM equivalent density, users must post-process the measured volumes and speeds reported by VISSIM. The HCM equivalent density can then be used to assign an HCM LOS letter grade. See HCM Equivalent LOS in [[#905.3.5.3.2.4.2 Post Processing|EPG 905.3.5.3.2.4.2 Post Processing]].

However, modelers should also remember that the ultimate goal of an analysis is most commonly to compare the performance of design alternatives in a design year. For this reason, using the density reported by VISSIM is typically acceptable and determining the HCM density equivalent (used to assign LOS) is often unnecessary. In this case, a “simulation LOS” can be reported using VISSIM-generated density and applying the HCM LOS thresholds.

''Note on Volume to Capacity Ratio''

Unlike deterministic software programs, VISSIM does not report volume to capacity (v/c) ratios. This is because both volume and capacity are highly variable in microsimulation. Although it is possible to calculate capacity at any given time, capacity is not constant. The capacity during one time period of the run may not be equal to the capacity during any other time period. Microsimulation also does not provide demand volumes. Rather, the model reports congestion and queuing, which are direct effects of a network being at capacity.

Instead of supplying v/c ratios, VISSIM produces the following information that conveys the relationship between traffic supply and demand:
:• Volume, speed, and density at given locations
:• Congestion duration at variable traffic volume flow levels
:• System-wide effect of congestion and queueing.

''Speed Contour Plots''

Statistics produced by link evaluation or data collection points may be used to create speed contour plots which are useful in demonstrating the intensity and duration of congestion. The link-by-link statistics gathered during initial link evaluation can be used to generate contour plots, or modelers may choose to rerun the link evaluation with smaller segments (can use 100-foot segment lengths) to improve the resolution of the plot.

Figure 905.3.5.3.2.4.1.2 shows an example of a speed contour plot where the x-axis shows the horizontal distance along a corridor and the y-axis shows temporal time distribution through a peak period. Individual cell locations are color coded to match speed range results.

[[image:905.3.5.3.2.4.1.2.jpg|850px|center|thumb|<center>'''Figure 905.3.5.3.2.4.1.2, Example of a Speed Contour Plot'''</center>]]
 
'''Other Output for Select Projects'''

MoDOT considers including the following information in a final report to be needed only for select projects, as agreed-upon during scoping. Modelers should review this list and include any topics which are relevant to the analysis at hand.

''Queue Counters''

Queue counters can be coded into VISSIM to measure queue lengths starting at the downstream position of the counter until the furthest upstream vehicle has entered queue conditions. Queue counters report average queue length, maximum queue length, and average number of stops for the defined time intervals. Queue lengths may extend as far as the next queue counter or as long as the maximum queue length specified by the user. According to the VISSIM User Manual, “If the queue backs up onto multiple different approaches the queue counter will record information for all of them and report the longest as the maximum queue length.” For this reason, modelers must place queue counters on all side streets to ensure the reported queue length is an accurate measurement of the queue on the actual roadway in question.

Queue counters can be coded under Evaluation/Configuration, as shown in Figure 905.3.5.3.2.4.1.3.

[[image:905.3.5.3.2.4.1.3.jpg|800px|center|thumb|<center>'''Figure 905.3.5.3.2.4.1.3, Queue Counter Evaluation Dialog Boxes'''</center>]]

If a project requires calculating average and 95<sup>th</sup> percentile queue lengths, modelers should record queuing information in 120-second intervals. The data set from the queue counters over the multiple simulation runs must be compiled and the list of all maximum queues for each movement must be averaged together to get the “average of the max.” The standard deviation from this data set must also be calculated. With these two values the 95<sup>th</sup> percentile queue can be calculated using the formula (same calculation as used in the SimTraffic microsimulation software package):

<center>95<sup>th</sup> percentile queue = average of the max queues + 1.65 * standard deviation</center>

It is MoDOT’s preference that <u>maximum queue</u> values be directly extracted from the VISSIM node or queue counter functions. If the project needs to use 95<sup>th</sup> percentile queue information, that will need agreement and justification during the project scoping process.

Additionally, custom aggregation percentiles for queues (or any other defined MOE statistic) can be specified in the Result Management tab of the Evaluation->Configuration window within VISSIM. The percentile calculations do not use the estimation formula as shown above for 95<sup>th</sup> percentile queues and again, will need to be justified for use during the project scoping process in lieu of reporting maximum queue values.

''Data Collection Points (DCPs)''

Placement of DCPs should reflect the locations where field data were actually collected. If the model is being calibrated with archived speed or data volume, DCPs should be placed as closely to the original data collection locations as possible.

After coding and naming all DCPs, modelers must create data collection measurements (DCMs) to extract vehicular counts and spot speeds at DCPs. These DCMs can be coded individually to capture lane by lane data or grouped to show full roadway cross-sectional data. Data extracted from DCMs can be useful in creating speed comparison tables to compare field measurements with model outputs.

''Emissions''

Through node evaluation, VISSIM is able to report emissions output for CO, NOx, VOC, and inputs needed for the EPA’s Motor Vehicles Emissions Simulator. If a project requires EPA compliant emissions, VISSIM does have the capability to interface with external emissions models. If emissions are being used simply to compare alternatives, VISSIM’s emissions reports are sufficient.

''Lane Changes''

Lane change output is used most often when comparing design alternatives for weaving sections. VISSIM’s lane change output provides a record of each lane change maneuver with a time stamp, as well as the origin and destination lanes of the maneuver. This information can help to compare alternatives, where alternatives that produce fewer lane changes are likely preferable. However, users should make note that VISSIM does not allow for filtering by link number before recording. Finding the records of lane changes made in the segment in question requires post-processing filtering, which can be time consuming and costly.

''Managed Lanes''

If a project requires use of VISSIM’s managed lane add on module to account for HOV or other managed lanes, modelers can use the managed lane output option to report more detailed information about the network’s performance. Additional details include the following:
:• Average speed on managed lanes
:• Average speed on general purpose lanes
:• Travel time savings for managed lanes routes
:• Tolls collected in the managed lanes by vehicle class

''Delay Segments''

Delay segments in VISSIM can be used for several purposes, including the following:
:• Collecting intersection MOEs at locations with unusual geometry
:• Measuring delays for a movement through multiple intersections
:• Measuring the delay along a specific path along a network
:• An alternative to node evaluation for networks with a unique street system

When using this option, the user defines the start and end of the delay segment and assigns it a number. To do this, the user must first define travel time segments for each movement and then combine them as delay segments. Although this process is labor intensive at first, it allows for the user to have complete control over how delay segments are defined.

''Green Time Distribution''

The green time distribution option may be useful if there are signalized intersections in the VISSIM model where the signal timing changes from cycle to cycle. The signal timing may change due to actuation or because of transit signal priority or railroad preemption. The option reports the average green and red times for each signal phase and a summary table of each value of green and red times recorded.

''Vehicle Record''

VISSIM’s vehicle record option can be used to report vehicle performance characteristics, such as position, instantaneous speed and acceleration, desired speed, and lane, in the network for every time step. This option is most normally used to collect data that will be exported to a third-party software program for visualization purposes.

''Public Transport Waiting Time''

VISSIM’s public transport waiting time option aggregates the amount of time a transit vehicle stops for any reason other than a designated transit stop or a stop sign coded with a dwell time. This wait time is largely a sum of the time spend at traffic signals or waiting in congestion.

=====905.3.5.3.2.4.2 Post Processing=====
VISSIM data requires some post-processing to arrive at a truly accurate representation of a model’s predictions. Because randomization is inherent to the microsimulation process, modelers should average the results from several runs using different random number seeds to develop the most correct interpretation of the model.

Post-processing methods may vary from modeler to modeler; however, spreadsheets are commonly used because VISSIM data is usually output as a delimited text file. Modelers should take care to outline their post-processing procedures, and any spreadsheets they plan to use for post-processing, in a Methods and Assumptions report. Modelers should also note that standard deviation for all data should be reported when possible and that the random number seeds used to produce runs should be recorded and reported to ensure that their results can be replicated later.

Post-processing is also sometimes carried out using VISSIM’s built-in Data Analyzer feature. The Data Analyzer can generate reports from Node Evaluation and Travel times data, however, doing so requires a significant amount of time to collect the data and run the data analyzer. This saves modelers from having to sort through raw data themselves, but modelers are still expected to review their raw data to determine standard deviation and identify outliers if they choose to use this method.

''HCM Equivalent LOS''

During scoping, it should be determined if HCM methodology for analyzing freeway segments will be strictly followed. If LOS is the main MOE used, then this is recommended, and the following guidance applies:
:• For typical freeway merges and diverges, density should be calculated for every 15-minute period using the average density (weighted by lane-length) of the acceleration/deceleration lane(s) and the two adjacent freeway through lanes for a length of 1,500 ft. from the painted gore point. For example, if a merge includes a 1,000 ft. acceleration lane, then the average density output by VISSIM for the acceleration lane and each of the two adjacent through lanes should be multiplied by 1,000 ft. and added together. This should then be added to the average density of each of the two outer through lanes downstream of the acceleration lane multiplied by 500 feet. The overall total should be divided by the total lane-length of the merge segment (in this case 3 x 1,000 ft. + 2 x 500 ft. = 4,000 ft.).
:• Weave density should be calculated for every 15-minute period using the average density (weighted by lane-length) of the weave area (between the painted ramp gores) and each of the two 500-ft. segments on either side of the weave area. For example, for a three-lane freeway with a 3,000 ft. weave area (with a single auxiliary lane) the average density for the weave area would be multiplied by 3,000 ft. times four lanes and added to the density of the segments on either side multiplied by 500 ft. times three lanes. The overall total should be divided by the total lane-length of the weave segment (in this case 4 x 3,000 ft. + 2 x 3 x 500 ft. = 15,000 ft.).

The resulting density can then be assigned an “equivalent LOS” based on HCM thresholds. Without this post-processing, LOS can still be assigned using HCM thresholds, but should be reported as “simulation LOS.”

=====905.3.5.3.2.4.3 Visualization of Simulation Results=====
In addition to post-processing using spreadsheet tools or VISSIM’s Data Analyzer, modelers may choose to explore some of VISSIM’s options for visual displays and interpretations of simulation data. Several of these advanced options are listed and briefly described here:

'''Output plots:''' VISSIM can generate relatively simple plots for several output parameters, including but not limited to, Node outputs, Link segment outputs, Vehicle Travel Time results, and Queue results. VISSIM can output these plots as line graphs or bar charts based on how the user would like to illustrate the given data.

'''Network heat maps:''' VISSIM also has the capability to generate heat maps that represent link performance measures such as average speed, density, and volume. These maps convey how performance measures vary spatially within a network, making them a powerful visual aid. These heat maps can be generated using VISSIM’s pre-defined color schemes, or with a color-scheme of the user’s choosing.

'''Ancillary performance visualization:''' Similar to heat maps, VISSIM can generate ancillary performance visualizations as an alternative way of conveying network performance measures. These performance measures include but are not limited to VISSIM calculated LOS, queue lengths, and throughput volumes. Ancillary performance visualizations can be helpful when generating final reports, but also as a relatively fast way to evaluate the reasonableness of a model’s output.

=====905.3.5.3.2.4.4 Video Presentation=====
In addition to static visual presentations, video presentations can also be a powerful way to illustrate and validate model performance. VISSIM offers several different types of video presentation, each of which are defined and briefly below:

'''2D Vehicle Animations:''' Two-dimensional animation is shown within the VISSIM user interface during simulation runs and is very useful for model debugging and validation. However, this method is not as effective as other methods when communicating results and outputs.

'''Real-Time Network Performance Results:''' Similar to the way performance metrics can be included in visual presentations of models, figures illustrating speed, volume, density, queue length, intersection performance, and other metrics can be included in model animations. Showing real-time performance results can be especially useful in showing the build-up and break-down of congestion during peak periods. Still visual presentations can be used in a report to communicate performance metrics at specific times, while animations can be used to show how performance metrics change over time.

'''3D Animation:''' Although not as commonly used as two-dimensional animations, three-dimensional animations can provide realistic illustrations of transportation networks that are especially useful when presenting to non-technical audiences. Using VISSIM’s 3D mode, modelers can create animations by recording a simulation from fixed camera viewpoints and sequences in a storyboard. Users also have the option of using a standard aerial background for their animations, or they can choose to incorporate other background elements from Google Sketchup’s online warehouse or custom made in Google Sketchup. Further editing can also be done using an external video-editing software. Modelers should note that while three-dimensional animations can be effective aids when presenting results, generating these animations is often resource intensive. The need for three-dimensional animations should be discussed with MoDOT and other stakeholders before proceeding.

==905.3.5.4 Other Software==
There may be situations where the contextual needs of the project make it necessary to use one or more analysis tools that are not addressed in EPG 905.3 Transportation Impact Analysis. In these circumstances, please discuss the situation with MoDOT and local planning partners as early as possible while scoping the project. Once it is collaboratively agreed upon what analysis software should be used, the analyst should document the selected software and the key reasons for selecting the software in the MoDOT [[media:905.3.2.5 TIA Methods and Assumptions Report.docx|TIA Methods and Assumptions Report]].

'''Congestion Mitigation and Air Quality (CMAQ) Emissions'''

CMAQ provides flexible funding that may be used to reimburse eligible project sponsors for projects or programs that will contribute to attainment of the National Ambient Air Quality Standards (NAAQS). The East West Gateway Council of Governments (COG) includes the metropolitan St. Louis area, which is the only metropolitan area in Missouri subject to the CMAQ application process.

The East West Gateway COG application states that the project sponsors may be asked to estimate emissions reductions data. The emissions data is generated from the EPA’s Motor Vehicle Emission Simulator (MOVES) model, not from other modeling sources. For more information about this process, refer to the East West Gateway COG 2020 [https://www.ewgateway.org/wp-content/uploads/2020/04/CMAQ-Workbook-110819-CFP-2020.pdf CMAQ Project Development Workbook].

==905.3.5.5 Model Templates==
Generic project file templates are provided for the software tools listed below. These file templates are accessible by MoDOT personnel and are a reference for users, which accompany the guidance in EPG 905.3 Transportation Impact Analysis. These files may be shared with external customers upon request.
:• [https://modotgov.sharepoint.com/sites/ts/Safety%20Engineering%20%20Data/Forms/AllItems.aspx?id=%2Fsites%2Fts%2FSafety%20Engineering%20%20Data%2FShared%20Documents%2FStudies%2FTransportation%20Impact%20Study%20Guidance%2FBase%20Model%20Files&viewid=ead934a0%2D4e9f%2D471b%2Db195%2D1e5c453a37bd HCS]
:• [https://modotgov.sharepoint.com/sites/ts/Safety%20Engineering%20%20Data/Forms/AllItems.aspx?id=%2Fsites%2Fts%2FSafety%20Engineering%20%20Data%2FShared%20Documents%2FStudies%2FTransportation%20Impact%20Study%20Guidance%2FBase%20Model%20Files&viewid=ead934a0%2D4e9f%2D471b%2Db195%2D1e5c453a37bd SIDRA]
:• [https://modotgov.sharepoint.com/sites/ts/Safety%20Engineering%20%20Data/Forms/AllItems.aspx?id=%2Fsites%2Fts%2FSafety%20Engineering%20%20Data%2FShared%20Documents%2FStudies%2FTransportation%20Impact%20Study%20Guidance%2FBase%20Model%20Files&viewid=ead934a0%2D4e9f%2D471b%2Db195%2D1e5c453a37bd Synchro/SimTraffic]
:• [https://modotgov.sharepoint.com/sites/ts/Safety%20Engineering%20%20Data/Forms/AllItems.aspx?id=%2Fsites%2Fts%2FSafety%20Engineering%20%20Data%2FShared%20Documents%2FStudies%2FTransportation%20Impact%20Study%20Guidance%2FBase%20Model%20Files&viewid=ead934a0%2D4e9f%2D471b%2Db195%2D1e5c453a37bd VISSIM]

==905.3.5.6 Review Checklists==
In addition to base model templates, project scoping and software analysis tool checklists are available. These checklists are intended to guide MoDOT project reviewers as they review the scoping and software analysis completed for a project.
:• [[media:905.3.5.6 TIA Scoping Reviewers Checklist.docx|Project Scoping (TIA Scoping Reviewer’s Checklist)]]
:• [[media:905.3.5.6 HCS Checklist.docx|HCS]]
:• [[media:905.3.5.6 SIDRA Checklist.docx|SIDRA]]
:• [[media:905.3.5.6 SynchroSimTraffic Checklist.docx|Synchro/SimTraffic]]
:• [[media:905.3.5.6 VISSIM Checklist.docx|VISSIM]]

=905.3.6 Safety Analysis=
==905.3.6.1 Existing Safety Analysis==
===905.3.6.1.1 Purpose===
A complete safety study includes two parts: Analysis of crash history, and estimation of crash future. EPG 905.3.6.1 Existing Safety Analysis is about crash history and [[#905.3.6.2 Safety Modeling|EPG 905.3.6.2 Safety Modeling]] is about crash future.

TIAs provide essential information for a wide range of project types and are required for projects under the jurisdiction of MoDOT. The following guidance is intended to serve as a resource for practicing MoDOT Project Managers and consultants when completing or reviewing TIAs on various types of projects that include an existing safety analysis component. These guidelines are consistent with MoDOT's traffic safety standards of practice.

===905.3.6.1.2 Introduction===

TIAs are required for several different types of projects. These project types include, but are not limited to, the following:
:• Planning study
:• Traffic analysis study
:• Environmental study
:• Access Justification Report (AJR)
:• Proposed development.

Safety analysis consists of locating crashes at a particular location based on predetermined criteria and should be a component of these studies when crash data is available. Analysis of safety data is conducted in a similar manner for each of these studies, however, there are differences in the purpose depending on the work product being completed.

For example, a safety analysis for a planning level study should be done at a higher level of analysis (as the project study limits tend to be broader) while a review of crash history is focused more on overall trends that may or may not be known at the time of the project. Identifying these patterns early during the planning phase allows time for additional considerations to be made and implemented on time. This differs from a work product, such as a traffic analysis study, which typically occurs later in the project’s life when the scope and limits have become more defined. The safety information is similar in format, but the intent and purpose should be catered to the work product.

TIAs typically have a threshold of 100 new trips or identified safety issues in the area to trigger a safety study. However, MoDOT will make the determination on the need for a safety study if it is in question.

===905.3.6.1.3 Parameters===

The following are a list of parameters to be determined prior to completing crash analysis.

'''Analysis Type'''

The type of crash analysis can differ based on the project type. There are three types of crash analyses: sections, intersections, and networks. Depending on the project, one or more types of analyses may be needed.

:• '''Section analyses''' are the preferred analysis type to be used for studies where the main concern is mainline crashes along a specific section of roadway. Examples include an interstate corridor or a rural secondary road.

:Section analyses require a begin and end point and include crashes along a corridor between these limits, including intersection related crashes, unless there is a project specific reason to exclude them. Example study limits for a section analysis are shown in Figure 905.3.6.1.3.1.

[[image:905.3.6.1.3.1.jpg|center|900px|thumb|<center>'''Figure 905.3.6.1.3.1, Section Analysis Study Limits'''</center>]]

:• '''Intersection analyses''' are the preferred analysis type to be used for studies where crashes at a specific intersection are the primary concern. Examples include a downtown intersection or a rural driveway access.

:Intersection analyses include crashes within 150 feet of an intersection along all approaches. This distance should be extended from the edge of pavement of the cross-street for each approach. They should be used if project considerations are expected to impact these types of crashes. Example study limits for an intersection analysis are shown in Figure 905.3.6.1.3.2. It should be noted that the recommended study limits of 150 feet may be extended at the analyzer’s discretion to capture impacts at any nearby driveway accesses that fall just outside the standard limits. The study area should be agreed upon by the project team, including FHWA when applicable, during project scoping. [[#905.3.2.5 Scope the Project|EPG 905.3.2.5 Scope the Project]] provides additional considerations when determining the study area.

[[image:905.3.6.1.3.2.jpg|center|900px|thumb|<center>'''Figure 905.3.6.1.3.2, Intersection Analysis Study Limits'''</center>]]

:Both analysis types should be used on the same project if project considerations are expected to impact both section and intersection crash types. Such as widening a downtown corridor while implementing traffic signal upgrades should have an impact on both section and intersection type crashes and therefore should be analyzed as such.
:• '''Network analyses''' are a combination of section analyses, often with one or more intersection analyses, too. For example, closing at-grade crossings while adding a new interchange will likely cause traffic to reroute through a network of sections and intersections, which need to consider not just the proposed changes in features, but also the changes in traffic patterns and volumes.

'''Location'''

It should be noted that the location reported for a crash may need to be reviewed, if possible. Most notably, crashes might be reported at the “intersection” of a minor route and a freeway, but review of the crash report is needed to determine if the crash was on the freeway level or on the minor route level, or might have happened near one of the ramp terminals instead of at the crossing of the two routes.

Likewise, crashes at a short feature might need a review of the crash reports to see if the reported location is where the crash started or ended, and how that location applies to the location being studied. For instance, crashes reported at a curve might actually be related to an issue prior to the curve. The smaller the data set (less than 30 crashes) the more significant such location issues tend to be.

Please contact the Traffic Management System (TMS) Help Desk at (573) 526-8055 or (573) 522-8464 to report incorrect crash reports.

'''Time Period'''

Typically, a study period of the most recently available five (5) full years of crash history data is standard for all crash analyses. Since there is typically a lag in crash data becoming available, please provide the most recent full years of complete data. Coordinate with the
study team to determine the timeframe of complete crash data currently available.

There may be exceptions to the five-year timeframe if significant changes have occurred at the location within this period. One exception would be for analyses focused on pedestrian/bicycle crashes or railroad crossing crashes, which are typically analyzed based on the most recently available ten (10) years of crash history data due to their infrequent crash occurrences. Other exceptions that come at the discretion of the analyzer are typically any other instances of infrequent crash occurrences, such as when analyzing data along corridors that carry less than 1,500 vehicles per day.

'''Study Limits'''

As stated, section analyses require a begin and end point that should include all affected sections and intersections. At a minimum, include the entire footprint of the project area and extend study limits as needed. Proposed projects should incorporate, within reason, all intersections and access points that are expected to experience a change in crashes, traffic patterns, or traffic volumes as a result of the project. This may require extending the study limits to ensure all impacted approaches, ramps, driveways, etc. are captured.

For instance, studies involving interstate, freeway, and expressway facilities should begin and end the crash analysis at least a half mile from the center of the beginning and ending interchanges, or at least 1,500 feet from the farthest-outside ramp gores, whichever is greater. This will ensure that all crashes related to the merge and diverge areas of those interchanges will be included, however, the analyzer may extend the study limits even farther to ensure all impacts are captured, such as when dealing with vertical grade issues. The study area should be agreed upon by the project team, including FHWA when applicable, during project scoping. [[#905.3.2.5 Scope the Project|EPG 905.3.2.5 Scope the Project]] provides additional considerations when determining the study area. Example study limits for an interstate section analysis are shown in Figure 905.3.6.1.3.3.

[[image:905.3.6.1.3.3.jpg|center|900px|thumb|<center>'''Figure 905.3.6.1.3.3, Interstate Section Analysis Study Limits'''</center>]]

'''Additional Resources'''

There are additional resources that can be used to assist in conducting existing safety analyses, such as the [http://modatazone.modot.org/index.php/safety MoDOT Crash Statistics Map]. This map allows users to get a visual representation of crashes and their locations across the state. It also allows users to pull historical crash data and filter that information based on various crash and roadway attributes, such as crash type or curve radius. Data can also be filtered by more specific criteria, such as crashes involving older drivers or pedestrians. Results can be exported to either Excel or PDF for use. Individual crash reports may also be available via the mapping tool. The retrieval and use of crash reports by external users will be determined by MoDOT.

Statewide average crash rate information is also a useful resource when performing a safety analysis. The most recently available statewide average crash rates can be obtained through MoDOT and are helpful in comparison of the crash rates of the study location with the statewide average crash rates of locations having a similar cross-section.

===905.3.6.1.4 Analysis===

The following are a list of calculations and analysis techniques to be used after completing crash analysis.

'''Segmentation'''

Section crash analyses can be segmented as needed; however, it should be done in a manner that ensures the data remains statistically valid when comparing to statewide average crash rates. Due to statewide average crash rates consisting of many miles of continuous corridors, segmenting the data too much may create sample sizes that are too small and lessen the validity of the comparison of the crash rates to the statewide average.

Examples of proper places to segment a section analysis include locations where cross-sections drastically change between corridor intersections (e.g., change in number of lanes) or if multiple project phase limits exist within the study limits. Segmentation may also be done on interstate or highway facilities at each interchange. As shown in [[#Corridor Crash Rate|Corridor Crash Rate]], segmentation of the crashes might be made to match segmentation of the AADT data, to facilitate calculations of crash rates. Segments should be broken along the corridor at the center of each overpass that has an interchange with the corridor. Note that segments less than a mile in length may show unusually high rates.

As a note, segment lengths do not need to be equal, as crash rates will be adjusted accordingly based on length. Example study limits for a segmented interstate section analysis are shown in Figure 905.3.6.1.4. Analyzers may extend the limits on cross streets as they see fit to ensure that all crashes are being considered.

[[image:905.3.6.1.4.jpg|center|950px|thumb|<center>'''Figure 905.3.6.1.4, Segmented Interstate Section Analysis Study Limits'''</center>]]
<div id="Corridor Crash Rate"></div>
'''Corridor Crash Rate'''

Crash rates are calculated using a combination of crash frequency and vehicle exposure. They are expressed in either crashes per 100 million vehicle miles traveled (HMVMT) for section analyses or in crashes per 100 million entering vehicles (HMEV) for intersection analyses.

Calculate the corridor crash rate as follows:

:::::<math> Crash\ Rate = \frac{Number\ of\ Crashes}{Exposure}</math>

::Where:
:::::<math>Exposure = AADT * \frac{365\ Days}{Year} * \frac{Number\ of\ Years}{1} * \frac{Segment\ Length\ (miles)}{1}</math>

'''Critical Crash Rate'''

Statewide average crash rates should be used for comparison to the corridor crash rate when available. The statewide average rate used for comparison is up to the analyzer’s discretion and should be one that best represents the characteristics of the study corridor. For example, occasionally US routes will function more similarly to a state or secondary road than to an interstate facility.

When appropriate and after discussing with the project team, it may be necessary to convert statewide average crash rates to critical crash rates using the Critical Crash Rate Formula, below, to remove the elements of chance and randomness. This method statistically adjusts the crash rate using the exposure from the study corridor to determine whether the corridor crash rate for a segment is significantly higher than the rate of other locations with similar characteristics based on Poisson’s distribution. Poisson’s distribution is defined as a discrete probability function that describes the number of events that may occur in a given time period given the average number of times that such an event would typically occur over that time. Since crashes are rare events the probability of their occurrence can be approximated based on this distribution.

Corridor crash rates equal to or greater than the critical crash rate may be considered significantly higher than average and not due to chance or randomness.

Calculate the critical crash rate as follows:

:::::<math> Critical\ Crash\ Rate = Statewide\ Average\ Rate + K * \sqrt{\frac{Statewide\ Average\ Rate}{Exposure}} + \frac{1}{2 * Exposure}</math>

::Where:
:::::<math>K = probability\ factor = 1.645\ (95%\ confidence\ level)</math>
:::::<math>Exposure = AADT * \frac{365\ Days}{Year} * \frac{Number\ of\ Years}{1} * \frac{Segment\ Length\ (miles)}{1}</math>

'''Crash Statistics'''

Results from the crash analyses should be summarized in a report format and include the following basic statistics:
:• Study limits
:• Segment length
:• Annual average daily traffic
:• Total number of crashes
:• Crash rates and comparison to statewide average crash rates
:• Summary of crash types (e.g., rear ends, sideswipes, etc.) and percentages
:• Summary of crash severity and percentages
:::{| border="1" cellpadding="5" cellspacing="0"
|-
|MoDOT Injury Severity Classification||KABCO Injury Severity Classification
|-
|align="center"|Fatal Injury||align="center"|K
|-
|align="center"|Serious Injury||align="center"|A
|-
|align="center"|Minor Injury||align="center"|B & C
|-
|align="center"|No Injury Apparent||align="center"|O
|}
:• Summary map of all crashes in the study area
:• Summary of locations with patterns of crashes that may need to be addressed.

'''Crash Patterns'''

As stated above, the crash analysis should be reviewed to determine if specific crash patterns exist and outlined in the traffic analysis report. Crash reports should be reviewed as needed to determine location and accuracy of information. For instance, crashes may have occurred on a side street but coded as having occurred on the mainline. Other locations may have fewer crashes, so a more thorough review of the crash reports is feasible and provides the analyst with a better understanding of the crash issues.

Patterns can include, but are not limited to the following:
:• Time of day
:• Day of week
:• Light conditions (Day or Night)
:• Weather conditions (Wet)
:• Pavement condition (Wet)
:• Pedestrian/Bicycle crashes
:• Vehicle mix (e.g., high percentage of truck crashes).

Crash patterns should be reviewed further at specific types of locations that are more likely to have them, while also factoring in the proposed improvements and whether they would address the crashes For example, horizontal curves may have lane departure crash patterns due to substandard superelevation, inadequate paved and/or grass shoulders, and/or issues with stopping sight distance and/or passing sight distance. Vertical curves may have lane departure, rear end, and/or sideswipe crash patterns due to inadequate stopping or passing sight distance issues. Intersections may have angle, left turn-different roadway, left-turn-same roadway, rear end, or other crash patterns. These patterns tend to differ based on the configuration of the intersection and whether it is signalized or unsignalized.

The level of in-depth analysis is dependent on each situation. For example, a project near a school may require a more detailed review of time of day crash patterns, while a project in a downtown area may require a more detailed review of pedestrian/bicycle crashes. At the same time, freeway sections may require a review of wet weather or wet pavement related crashes. Certain types of projects or locations may dictate more detailed reviews of crash patterns. These reviews typically require examination of the individual crash reports completed by the police (either state highway patrol or local police officers). Engineering judgment and comparison of the various data points on the crash report are needed when reviewing the crash reports to ensure the crash is accurately represented (especially crash location). Data points on the crash reports to compare include the location and reference roads, crash narrative, and diagram.

'''Summary of Results'''

The safety analysis component of the report should include an introduction with background information to include the project description, project limits, crash analysis method and crash analysis time period determined from the guidance outlined above. A comprehensive summary of the crash statistics collected and analyzed should be produced for this section, including number of crashes and crash rates of the study area and their comparison to the statewide and critical crash rates. Lastly, the summary of results should include descriptions of notable crash patterns in the study area and additional information, if pertinent. Pie charts, figures, tables and heat maps are also helpful tools to depict the crash information to stakeholders.

An evaluation of the results of the crash analysis should be completed, including an interpretation of the results and what may be contributing factors to the observed crash patterns. Understanding why crashes are occurring can help in the project scoping process and can help determine purpose and need for a project. Traffic safety countermeasures should be proposed to address the crash patterns. The [https://safety.fhwa.dot.gov/rsdp/hsm.aspx ''Highway Safety Manual''] provides comprehensive countermeasure selection guidance for the various crash pattern types for particular locations, including along roadway segments, signalized and unsignalized intersections, and bicyclist and pedestrian related issues.

==905.3.6.2 Safety Modeling==
===905.3.6.2.1 Purpose===

A complete safety study includes two parts: Analysis of crash history, and estimation of crash future. [[#905.3.6.1 Existing Safety Analysis|EPG 905.3.6.1 Existing Safety Analysis]] is about crash history, while EPG 905.3.6.2 Safety Modeling is about crash future.

Historical crash data is not always readily available for Transportation Impact Analyses and may not apply to future conditions, especially for new construction projects; therefore a method of analysis that does not solely rely on historical data is necessary in order to quantify impacts to safety. The following guidance is intended to serve as a resource for practicing MoDOT Project Managers and consultants when completing or reviewing Transportation Impact Analyses on various types of projects that require a predictive (future) safety analysis component. These guidelines are consistent with MoDOT’s traffic safety standards of practice.

===905.3.6.2.2 Introduction===
As a component of the TIA, a future crash analysis is performed to evaluate the impacts that proposed geometric changes to the existing roadway and a change in traffic volumes will have on the overall safety performance of the corridor. Several modeling platforms that estimate the safety performance of design alternatives include:
:• MoDOT Crash Prediction Tool, for rural 2-lane routes.
:• [[#905.3.6.2.4 Highway Safety Manual (HSM) Spreadsheets|Highway Safety Manual (HSM) Spreadsheets]], for urban arterials, rural 2-lanes, or rural multi-lanes.
:• [[#905.3.6.2.5 Enhanced Interchange Safety Analysis Tool (ISATe)|Enhanced Interchange Safety Analysis Tool (ISATe)]], for freeways and interchanges.
:• [[#905.3.6.2.6 Interactive Highway Safety Design Model (IHSDM)|Interactive Highway Safety Design Model (IHSDM)]], for many types of routes.

These safety analysis tools utilize Part C of the ''Highway Safety Manual'' (HSM) to estimate the number of crashes based on the geometric characteristics and traffic volume of the facility.

'''Predictive versus Expected'''

The HSM is based on estimating crashes as "predicted" or "expected".
:• Predicted Crashes – Predicted crashes are based on the geometry, volume, and national pattern of crashes and are calculated within these safety tools utilizing standard Safety Performance Functions (SPFs)
:• Expected Crashes – Expected crashes are determined by adjusting the predicted crashes to include local crash history as a way to determine more accurately the modeled number of crashes.

MoDOT prefers that expected crashes be determined where existing crash data is available and where the geometry is similar to that of existing (e.g., adding rumble strips to a highway as opposed to rebuilding a cloverleaf interchange as a fully directional interchange). This provides more robust results that conform more closely to real world conditions. A methodology for determining future expected crashes is discussed in [[#905.3.6.2.7 Analysis Approach|EPG 905.3.6.2.7 Analysis Approach]].

'''Model Option Overview'''

Although these modeling platforms are all based off Part C of the HSM and will yield similar results, the method in which the analysis is conducted as well as the level of detail in the results differs. There are several modeling tools based on Part C of the HSM, including:
:• MoDOT Crash Prediction Tool
:::o Analyzes rural two-lane highways only
:::o Used for network screening and project analysis
:::o Utilizes TMS Data
:::o Automates crash analysis
:::o Provides both predicted and expected crashes
:::o Provides the Level of Service for Safety (LOSS)
{| style="padding:0.3em; margin-left:15px; border:2px solid #a9a9a9; text-align:center; font-size: 95%; background:#f5f5f5" width="460px" align="right"
|-
|'''Additional Information about Calibration Factors'''
|-
|MoDOT has a list of preferred calibration factors that should be utilized with these various modeling tools. The calibration factors are designed to provide predicted and expected crashes that more closely correspond to real world conditions in Missouri.
|-
|[https://www.modot.org/research-publications MoDOT’s research documents]
|-
|[https://spexternal.modot.mo.gov/sites/cm/CORDT/cmr18-001.pdf Missouri Highway Safety Manual Recalibration (February 2018)]
|-
|[https://spexternal.modot.mo.gov/sites/cm/CORDT/cmr16-009.pdf Highway Safety Manual Applied in Missouri – Freeway/Software (June 2016)]
|-
|[[media:905.3.6.2.2 Summary spreadsheet.xlsx|Summary spreadsheet]]
|}
<div id="HSM Spreadsheets"></div>
:• [[#905.3.6.2.4 Highway Safety Manual (HSM) Spreadsheets|HSM Spreadsheets]]
:::o Various spreadsheets have been developed by various sources, currently including analysis for rural two-lane and multi lane highways and urban/suburban arterials
:::o Provide high-level overviews of the expected and predicted number of crashes within a study corridor
:::o Require fewest number of input variables
:::o Require the user to determine segmentation and other inputs based on HSM guidance
:::o Do not analyze interchanges
:::o Good for corridors with few intersections
<div id="ISATe"></div>
:• [[#905.3.6.2.5 Enhanced Interchange Safety Analysis Tool (ISATe)|ISATe]]
:::o A version of the HSM Spreadsheet for freeways.
:::o Allows for the analysis of freeway and speed change lanes (i.e., acceleration, deceleration, and weave lanes) as well as ramps and ramp terminals
:::o Requires greater number of input variables than the HSM Spreadsheets
:::o Requires the user to determine segmentation and other inputs based on HSM guidance
:::o Can be used for any type of freeway corridor, though more complex suburban and urban freeway corridor may be more suited to model using IHSDM
:::o Can be used in conjunction with other HSM Spreadsheets if a local connecting road system needs to be analyzed as well
<div id="IHSDM"></div>
:• [[#905.3.6.2.6 Interactive Highway Safety Design Model (IHSDM)|IHSDM]]
:::o Fully integrated modeling software that allows for modeling most types of facilities as an interconnected network. There are instances where the HSM Part C does not apply to a real-world situation and cannot be modeled. Please refer to the HSM Part C.
:::o Requires highest number of input variables
:::o Determines segmentation automatically

MoDOT has a list of preferred calibration factors that should be utilized with these various modeling tools. The calibration factors are designed to provide predicted and expected crashes that more closely correspond to real world conditions in Missouri.

'''Tool Versioning'''

Various sources have developed each of these tools, though they all utilize the HSM to conduct their analysis. It is important to determine through consultation with MoDOT the appropriate tool and tool version for a specific project. The same version of the approved tool should be used throughout the entire course of the project unless instructed to utilize another version by MoDOT.

===905.3.6.2.3 [http://tms/bi/apps/crashpredict/report MoDOT Crash Prediction Tool]===

The Crash Prediction Tool developed by MoDOT is available for internal MoDOT use only. It allows for the analysis of rural two-lane highways only and provides the potential for safety improvements within a corridor. It automates the analysis utilizing the HSM for the selected corridors to determine predicted and expected crashes.

===905.3.6.2.4 Highway Safety Manual (HSM) Spreadsheets===

Following the guidelines presented in the HSM Part C, a method for estimating expected average crash frequencies at individual sites, the National Cooperative Highway Research Program (NCHRP) developed a collection of spreadsheet tools to assist with evaluating a variety of roadway types. HSM spreadsheets are available for the following roadway types (the chapter of the HSM devoted to each spreadsheet is noted as well):
:• Rural Two-Lane Roads (HSM Chapter 10)
:• Rural Multilane Highways (HSM Chapter 11)
:• Urban and Suburban Arterials (HSM Chapter 12).

Utilization of the HSM Spreadsheets requires segmentation of the corridor manually. The corridor should be divided into individual sites consisting of homogenous segments and intersections. These segments should be no less than 0.10 miles to minimize calculation efforts and not affect the results. Roadway segments begin and end at the center of intersections or where the homogenous roadway segment changes.

===905.3.6.2.5 Enhanced Interchange Safety Analysis Tool (ISATe)===

ISATe (HSM Chapters 18 and 19) is a specialized spreadsheet analysis tool that was developed to analyze freeways, ramps and ramp terminals.

Segmentation of the corridor utilizing ISATe requires the user to manually divide up the corridor for entry into the spreadsheet. Each segment should be homogeneous with respect to traffic volume, geometric design features and traffic control features. Changes in any of the following characteristics require a new homogeneous segment to begin within the model.
:• Number of through lanes changes.
:• Lane wide changes by more than 0.5 ft.
:• Inside or Outside shoulder width changes by more than 1ft.
:• Median width changes by more than 10 ft.
:• Ramp presence.
:• Clear zone changes by more than 5 feet.

The presence of a horizontal curve on its own does not define a segment boundary; one of the above characteristics must change. The same general guidelines apply to Collector/Distributor Roads within ISATe. For detailed explanations of the segmentation process, refer to the ''ISATe User Manual'' included with the spreadsheet model.

===905.3.6.2.6 Interactive Highway Safety Design Model (IHSDM)===

IHSDM is a safety modeling software developed by the Federal Highway Administration (FHWA), with the capabilities of evaluating freeways and arterials in both urban and rural areas. Using the HSM spreadsheets as the core function of the modeling software, IHSDM automates the segmentation process and provides a visual representation of what is being modeled, based upon user defined inputs. The user also has the option to import a Land XML file containing the horizontal and vertical alignment information for every roadway, which can greatly speed up the development and accuracy of the modeling output.

===905.3.6.2.7 Analysis Approach===
MoDOT preferred methodology is to determine the future expected crashes and compare those to the existing expected crashes utilizing the appropriate modeling tool. This comparison allows for local crash characteristics to be taken into consideration when determining the effectiveness of proposed improvements.
To determine the future expected crashes, the ratio of expected to predicted crashes under the existing condition should be determined. This ratio can be utilized along with the future predicted crashes to extrapolate the future expected crashes. Professional judgment is needed to determine if one ratio is used for the entire project, or if subparts of the project have and use separate ratios. The following formula determines the future expected crashes.

::::::::<math>Future\ Expected = Future\ Predicted * \left ( \frac{Existing\ Expected}{Existing\ Predicted} \right )</math>

A typical modeling scenario would be:
:• Model existing predicted crashes
:• Model existing expected crashes by inputting existing crash information into the analysis tool
:• Determine the ratio of existing expected to existing predicted crashes
:• Model the proposed improvements to determine the future predicted crashes
:• Utilize the formula to determine the future expected crashes and compare to the existing expected crashes.

===905.3.6.2.8 Crash Modification Factors (CMF)===
Crash modification factors (CMF) are values used to determine the predicted reduction in crashes from implementing a chosen countermeasure(s). They can play an important role in a traffic safety benefit-cost analysis to determine the anticipated benefits of a countermeasure. A CMF value of less than 1 reflects a predicted reduction in crashes while a CMF value of greater than 1 reflects a predicted increase. The use of CMFs is consistent with the information contained in the HSM.

As referenced in [[907.5 S-HAL|MoDOT S-HAL: Safety Handbook for Locals]], one of the most accepted methods of assessing safety at a location is through the analysis of existing crash patterns to include frequency and severity. This information is obtained through the crash analysis summaries, crash reports provided by law enforcement, and collision diagrams. Analysis of this information allows the examiner to determine appropriate countermeasures, or safety treatments intended to mitigate crash patterns.

One or more countermeasures may be proposed in order to alleviate the existing crash patterns at the location. Countermeasure selections should be vetted through a project core team. This will allow MoDOT to better maintain countermeasure selection and track historical performance. Once possible countermeasures are selected, the responsible party should determine the appropriate CMFs to apply to the analysis.

'''CMF Selection'''

Contact the MoDOT project core team and central office MoDOT staff for the approved CMF list. If MoDOT does not currently have the appropriate CMF on their approved list, they may recommend the use of the FHWA funded [http://www.cmfclearinghouse.org/ CMF Clearinghouse]. This site provides an online searchable database to find applicable countermeasures and the published CMFs established for each. As with countermeasure selection, CMF selection should be vetted through the project core team prior to using.

Each countermeasure within the site is assigned a star quality rating (1 to 5), with 5 representing the best rating, to indicate the confidence in the results of the study that produced the CMF. The rating is based on several factors, including design of study, sample size, data source, standard error, and potential biases. The clearinghouse also assigns star quality ratings for CMFs provided in the HSM.

Due to the extensive size of the CMF Clearinghouse database, a search for CMFs will often return many results even when using the filtered search feature therefore users will often need to decide which is the best CMF to use.

MoDOT guidance is to select the CMF with the best quality rating for conditions as similar to the project area as possible.
:1. '''Star quality rating –''' The star quality rating indicates the quality of the CMF. As noted previously, the ratings range from 1 to 5, with 5 being the highest quality rating. The rating is based on five categories to include the design of the research, study sample size, standard error, potential bias, and data source. The star quality rating can be used to determine the most appropriate CMF to use if all major factors are similar.
:2. '''Score details –''' The clearinghouse assigns scores of excellent, fair, or poor for each of the rating categories. Details of the scores can be found within the star rating on many of the CMFs. This information is very helpful when comparing the results of two or more comparable CMFs.
:3. '''Similarity in locality of data used –''' Information related to the specific geographic region that the CMF was developed is provided for the user. It is preferable to use data based on similar topography, weather, and other factors if possible.
:4. '''Traffic volume range –''' A range of traffic volumes used in the CMF development is provided for the user to select the most applicable CMF. It is at the analyst discretion whether to allow for going out of range if no other CMF is applicable.
:5. '''Age of data –''' All studies for CMFs provide a date range for the study performed. The CMF that uses the more recent date range is preferred if all other factors are similar.
:6. '''Original study report –''' The clearinghouse provides a link to the study report if it is available. This is often helpful to the user to gain insight on the study background.

CMFs are useful tools in the estimation of predicted impacts to crash reductions and/or increases. CMFs can be in different forms, such as crash type, crash severity, total crashes, etc. Due to the variability in location characteristics, driver behavior and other factors, actual reductions in crashes will vary. The standard error listed for each CMF is helpful in determining the anticipated effectiveness of a countermeasure.

When selecting the CMF(s), consider this guidance from the CMF Clearinghouse:
:• CMFs that most accurately reflect the characteristics of the location being investigated are the most appropriate.
:• More than one CMF may be applicable.
:• Use the CMF with the highest star rating, making sure that it is applicable to the proposed countermeasure and study location.
:• If all factors above are equal, then the more conservative value should be selected.
:• If there is no applicable CMF, contact the project core team for further guidance.

'''CMF Application'''

Once CMFs are determined, they are multiplied by the appropriate crash information (numbers of crashes, severity, types, etc.) as indicated by the CMF. Many CMFs will apply to all crashes, but some CMFs specifically apply to a particular crash type (e.g., rear ends) or crash severity (e.g., fatal and serious injury crashes). For predictive analysis, which is the recommended approach, the CMFs are multiplied by the predicted crash information to estimate the predicted number of crashes as a result of the improvement. This can then be converted to expected crashes using HSM methodology as outlined in [[#905.3.6.2.7 Analysis Approach|EPG 905.3.6.2.7 Analysis Approach]]. If predictive crash analysis is not possible, the CMFs are multiplied by the crash information as revealed in the crash history at the location. While not the preferred approach, this calculation provides a sense of the anticipated numbers of crashes as a result of the proposed countermeasure(s).

It is generally preferable to use a single CMF; however, it is also common for traffic professionals to recommend multiple countermeasures to address a crash pattern at a location. In order to accurately capture impacts for these types of situations multiple CMFs will need to be combined.

::::::::<math>CMF_{Total} = CMF_1 * CMF_2</math>

While multiplication of CMFs is an acceptable practice, it is undetermined if implementation of more than one countermeasure at a location will provide the full effect of crash reductions compared to countermeasures implemented individually. This overestimation of crash reductions grows more uncertain with the addition of more countermeasures at a given location. As a result, judgment should be applied when multiple countermeasures are proposed and MoDOT recommends capping the number of CMFs that are used to a maximum of three.

===905.3.6.2.9 Other Analysis Methods===
While HSM is the preferred method for safety analysis and should be used when applicable, there are scenarios that exist where exposure or geometric design thresholds may not allow for analysis through traditional HSM tools. Other methods of alternative safety analysis may include the measurement of exposure by counting the number of conflict points or number of weaving maneuvers, using other surrogate safety data, or calculating a crash rate based on the existing crash history and applying it to future traffic volumes.

===905.3.6.2.10 Surrogate Safety Assessment Model (SSAM)===

Another alternative predictive safety analysis tool that may be used on arterials is the Surrogate Safety Assessment Model (SSAM). The SSAM is a software application that automatically identifies, classifies, and evaluates traffic conflicts in the vehicle trajectory data output from microscopic traffic simulation models, such as VISSIM. Traffic conflicts are defined as an observable situation in which two or more road users approach each other in time and space to such an extent that there is risk of collision if their movements remain unchanged. The trajectory input data for the SSAM are generated by traffic simulation software in a format that is specifically designed for its use. The SSAM can also aid analysts in design with built-in statistical analysis features for conflict frequency and severity measures that can be used for comparing alternatives.

SSAM provides an option for assessing the safety of traffic facilities using popular microsimulation software. This approach eliminates the need to wait for a significant amount of crashes to occur, allows assessments of hypothetical designs and traffic control, and is applicable to facilities where HSM may not be applicable due to geometric design or volume thresholds. This technique is only expected to grow in use as simulation models and video technology continue to improve.

===905.3.6.2.11 Systemic Safety Analysis===
Site-specific analysis is the basis for identifying potential safety improvement projects for many traditional network screening techniques. These techniques often use historical crash data and crash severity to base decisions. Crashes occurring on rural roads account for a high percentage of severe injury crashes, however, the density of these crashes is typically low and does not lend well to identifying crash issues or locations of concern using a site-specific analysis process. These concerns are not only limited to crashes occurring on rural roads, as similar situations can exist in urban areas. Examples include crashes involving vulnerable road users, such as pedestrians, bicyclists, or motorcyclists.

'''Systemic Approach to Safety'''

A systemic approach to safety involves widely implemented improvements (e.g., median cable barriers) to a transportation system based on identified high-risk scenarios that correlate with specific crash patterns. This approach addresses crash types that contribute to a high portion of severe injury crashes across a network rather than focusing on specific locations with a pattern of severe injury crashes. This approach provides a more comprehensive method for safety planning as it considers both crash history and crash potential in decision-making.

The systemic approach is data-driven and could potentially suggest safety improvement projects that are not typically identified through the traditional site-specific analysis approach. The intent of this approach is not to replace the traditional site analysis, but to supplement it, and provide a proactive approach to preventing severe crashes. Both site-specific analysis and systemic approaches are necessary for an effective and comprehensive safety management program.

As a result, MoDOT has deployed a systemic approach to their safety planning and management efforts and currently has guidance for:
:• [https://epg.modot.org/index.php/903.6_Warning_Signs#903.6.11_Chevron_Alignment_Sign_.28W1-8.29_.28MUTCD_Section_2C.09.29 chevrons],
:• [[:Category:626 Rumble Strips|shoulder and rumble strips]], and
:• [https://epg.modot.org/index.php/606.2_Guard_Cable#606.2.2_Systematic_Application_of_Median_Guard_Cable median guard cable].

Project teams are responsible for reviewing to see if the project area has any locations that a systemic improvement would be applicable. Additional guidance will be incorporated as it is developed for other systematic improvements.

'''Systemic Safety Planning'''

Systemic safety planning is the process of evaluating an entire system against a defined set of criteria to identify locations for safety improvements to reduce the frequency and potential for severe injury crashes.

The systemic approach to safety planning can be summarized in the following steps:
:• Identify issue based on systemwide data, such as rural lane departure crashes, urban pedestrian crashes, or rural unsignalized intersection crashes. These crashes are often spread across the network with few or no locations experiencing an abnormally high cluster of crashes during a typical analysis period.
:• Identify characteristics frequently present in severe injury crashes. These characteristics, also known as risk factors, can be used to identify locations with potential for severe injury crashes despite not currently having a significant crash history.
:• Prioritize locations across a network. The concept is to evaluate an entire system for roadway characteristics identified as risk factors. The result will be an inferred prioritization indicating that some parts of the system are better candidates for safety improvement than others.
:• Focus on deploying low-cost countermeasures to address risk factors contributing to crashes on a majority of roads. Addressing low density crash types that contribute to a large aggregate number across the entire system will drive decision-making toward low-cost solutions that are widely deployed across the system to affect a large number of locations.

==905.3.6.3 Applications of Safety Analysis==
===905.3.6.3.1 Benefit-Cost Analysis (BCA)===
Benefit-cost analyses compare the present value of total project benefits to total project cost and are used to determine if safety improvements are economically feasible, or if the potential benefits are greater than the anticipated costs. A value greater than 1 means that the anticipated benefits of the project outweigh the anticipated costs. They also provide information on which traffic safety countermeasure(s) would provide the greatest benefit when factoring in cost, or if an improvement at one location would be more beneficial than an improvement (whether the same or different) at another location.

'''Benefits'''

The benefits of a traffic safety project are determined by calculating the total reduction in crashes and should be represented by HSM expected values when possible. This value can be calculated by using one of the various tools (HSM Spreadsheets, ISATe, IHSDM, etc.) stated in [[#905.3.2.1.2 Safety Analysis Tools|EPG 905.3.2.1.2 Safety Analysis Tools]].

MoDOT calculates safety benefits based on a reduction of crashes. These crashes are multiplied by a dollars per crash value, based on periodic FHWA determined values and adapted to Missouri’s Consumer Price Index. Contact the MoDOT project core team for the appropriate values to use for the study. The resulting benefit is in dollars saved due to crashes reduced. It should be noted that a negative number is possible and represents an expected increase in crashes.

Crashes reduced due to proposed safety improvements should be calculated for the service life of the improvement using the tools and methods outlined in this article, such as [[#905.3.2.1.2 Safety Analysis Tools|HSM Spreadsheets]]. Other tools such as ISATe or IHSDM can also be used to calculate annual benefits by estimating future crash performance with and without the countermeasure(s); however, they should be calculated for the present year of the countermeasure’s service life to be accurately compared with the cost analysis in [[#Costs|Costs]]. MoDOT practice is to calculate the total benefits of all crashes reduced, but also to consider the total benefits of only the fatal and serious injury crashes reduced. 

::::::::<math>Total\ Benefits = \sum Countermeasure\ Crashes\ Reduced * Associated\ Crash\ Costs</math>
<div id="Costs"></div>
'''Costs'''

Every traffic safety project has a variety of associated costs. MoDOT guidance is that safety costs represent the Highway Safety Improvement Program (HSIP) programmed amount for safety improvement construction. As a general guideline, right of way costs are only included if nearly all of the project is for safety improvements, such as those programmed with a primary category of safety. Also, typically engineering, design, construction inspection, and other incidental costs are not included, even for projects that are entirely safety improvements. Routine maintenance is typically not included if minor, however, if significant maintenance is required on an annual basis, such as for guard cable, then it should be included. All costs should be represented in present year dollars and if a project <u>needs to account for future costs</u>, such as significant maintenance, they should be converted into present year dollars.

All construction costs only associated with the safety improvement should be included in the cost analysis. If shoulders and rumble strips are being added during a resurfacing job, costs associated with the resurfacing should not be counted.

If future costs are required to be included, such as significant maintenance, it is necessary to convert them to make an accurate comparison. It is recommended to convert everything back to present year costs in order to compare to the total benefits, which are represented in present year dollars.

'''Service Life'''

The service life of a proposed improvement refers to its anticipated useful life. For example, a bridge would be expected to have a much longer service life than a warning sign. Service life information is used in the benefit-cost analysis to factor the expected useful life of the proposed countermeasure and should be collected on all items associated with the construction of the safety improvement.

The CMF Clearinghouse, as well as MoDOT’s pre-approved list of CMFs, provides a comprehensive listing of available service life information for commonly used traffic safety countermeasures. The information is provided by several states and organized consistently with the [http://www.cmfclearinghouse.org/resources_servlifecrashcostguide.cfm 15 countermeasure categories currently listed in the clearinghouse]. Three additional categories of Resurfacing, Structures, and Other are also available. Links to tables for each category are shown, and each state’s service life information is listed if it is available.

As stated previously, it is common for safety projects to include multiple countermeasures, which may have differing service lives. MoDOT guidance is to incorporate service life into the estimation of crash reductions by calculating the expected crash reduction for the entire initial life of the improvement. For example, a bridge project that also includes warning signs would estimate the crashes reduced by the bridge improvement over the life of the bridge, as well as the crashes reduced by the signs over the life of the signs. This results in the total number of estimated crashes to be reduced in the project area across the initial life cycle of each improvement. This method of analyzing crash reductions for only the initial service life of each improvement and not accounting for replacement of countermeasures with lesser service life cycles is preferred due to cost calculations generally only accounting for initial construction costs for each countermeasure. Accounting for replacement of countermeasures with lesser service life cycles also requires the life cycles of all countermeasures involved to have a common denominator otherwise determining the number of replacements to account for becomes more challenging. Therefore, it is recommended to calculate the value of the expected crash reduction for the entire initial life of the improvements compared to the total initial costs of the improvements plus any significant maintenance as stated above.

'''Benefit-Cost Ratio'''

After quantifying the total benefits and costs for the project, the benefit-cost ratio can then be calculated as follows:

::::::::<math>Benefit\ to\ Cost\ Ratio = \frac {Total\ Benefits}{Total\ Cost}</math>

A benefit-cost value of greater than one (1) means that the anticipated benefits of the project outweigh the costs. The ratio can be used as a comparison tool for countermeasure selection; however, it is ultimately up to professional judgment to determine the best possible countermeasure for the project rather than selecting the option that results in the highest value. MoDOT practice is to calculate two B/C ratios. One B/C ratio incorporates the total safety benefits using all crashes. The other B/C ratio is referred to as a Priority B/C that only focuses on fatal and serious injury crashes. The use of the Priority B/C analysis allows MoDOT to focus and prioritize safety projects that will maximize lives saved over a project that reduces property damage only type crashes. Other factors, such as the required time to implement and total cost, should also be factored into the decision. While the B/C must equal at least one in order to be eligible for safety funds, the intent of safety projects is to save the most lives and reduce the most serious injuries.

'''Documentation'''

The calculation of benefit-cost ratio should be well documented and cataloged for future reference. The number of anticipated lives saved, and serious injuries reduced should also be documented. This will be helpful not only for projecting cost and benefit of future projects, but also for evaluating benefit-cost analysis of past projects. Suggested items to include in this documentation are project information, such as study location, date, and proposed countermeasure(s), as well as information used in the benefit-cost analysis, such as project costs, service life, CMF(s) used and corresponding reference numbers if applicable, crash costs, and crashes saved. It is also important to include the required information for HSIP reporting, such as categories, AADT, and speed.

It is also recommended to document any special circumstances that may have had significant impacts to either costs or benefits. For example, a special circumstance that may be worth noting that would have an impact on benefits are locations that deploy an interim countermeasure. Significant impacts to costs should be accounted for as these are typically calculated on a location-specific basis.

===905.3.6.3.2 [[131.1 Design Exception Process|Design Exceptions]]===

MoDOT policy requires adherence to established engineering standards regarding geometric design and related design features. However, instances can occur during the design phase of the project when it is not reasonable for a design element to meet the established criteria. In these cases, design exceptions may be required. Design exceptions are completed to document the reasoning why it is not feasible to meet established MoDOT engineering policy for given design elements. The documentation consists of the engineering-based decisions used to justify an approach that would not meet the established standards. Contact the project core team to determine if design exceptions are needed for the study section.

'''Safety Analysis Documentation'''

MoDOT requires that any design exception request, related to safety, have a comparison of expected crashes if meeting design standards, with expected crashes with the proposed design exception. Refer to [[#905.3.6.2 Safety Modeling|EPG 905.3.6.2 Safety Modeling]] for additional information. The HSM provides tools to complete the comparative analysis. This information is included in the submitted documentation to support the recommended exception to engineering policy. Safety related design elements include design speed, lane widths, alignments, clearances, etc. When it is undetermined that a roadway feature is safety-related, it is recommended to presume it is safety-related and provide the necessary safety analysis documentation.

Exception requests require full analysis, crash history and crash prediction. Engineering judgment should be applied to determine the appropriate type of analysis. The HSM does not distinguish between sections and intersections. However, the analysis should differentiate based on roadway types (e.g., interstates versus rural two-lane roadways). There may be some instances where an HSM analysis would not be applicable, such as a low volume or low exposure roadway of less than 400 vehicles per day. In these cases, a comparison of crash rates for the section of roadway to the statewide crash rate would be more appropriate. Please contact the MoDOT project team to determine if this alternative safety analysis is the recommended approach.

A review of the results of the safety analysis should be completed by a qualified practitioner to determine if crashes are reduced or if they increase if the design standard is not met. The costs can then be calculated to compare the costs of construction versus the cost of crashes. This information allows the project team to quantify the crash risk with the alternatives, so this risk can be weighed with other project constraints, such as cost, environmental impacts, right of way, etc.

'''Mitigation'''

To lessen the negative safety impact of a design exception, mitigating treatments may be recommended and implemented. For example, if it is not feasible to realign a horizontal curve to a 55-mph design speed due to design constraints, appropriate curve warning signs with advisory speed plaques and chevrons may be recommended. Mitigating treatments relating to warning signs or other traffic engineering features are often investigated by a traffic engineer or other qualified practitioner who is well-versed in traffic safety.

'''Conclusions'''

While design exceptions are necessary when certain design criteria cannot be reasonably met, they can also be viewed as allocating resources in a more sensible manner. Documentation of the design exception request, including the safety analysis, is essential for the appropriate staff to make an informed decision.

=905.3.7 Sample Report Templates=
==905.3.7.1 Methods and Assumptions Report Template==

A [[media:905.3.2.5 TIA Methods and Assumptions Report.docx|TIA Methods and Assumptions Report]] serves as a record of the decisions and agreements made by the advisory team at the outset of a project. This is a template that is meant to aid consultants and other parties submitting work to MoDOT in their consistent scoping and review of TIAs.

==905.3.7.2 Calibration Report Template==

A [[media:905.3.5.2.3.2 Calibration Report.docx|Calibration Report]] is meant to serve as proof that a microsimulation model has been adjusted to better replicate real world conditions and its ability to replicate real world conditions has been thoroughly validated using observed counts and measurements. This template is meant to aid consultants and other parties submitting work to MoDOT in their production of Calibration Reports.

==905.3.7.3 TIS Report Template==

A [[media:905.3.7.3_MoDOT_Traffic_Impact_Study_Report_Template_06_17_2020_FINAL.docx|Traffic Impact Study (TIS) Report]] is meant to summarize the procedure and findings of traffic impact studies and to recommend adjustments to the transportation network that will be needed to handle the traffic generated by the construction of new developments. This template is meant to aid consultants and other parties submitting work to MoDOT in their production of TIS Reports.

==905.3.7.4 Traffic Safety and Operations Report Template==

The purpose of a [[media:905.3.7.4_TS&O_Report_2022.docx|Traffic Safety and Operations (TS&O) Report]] is to analyze the current performance of a roadway, the future performance of the roadway without improvements, and the future performance of the roadway after improvements have been made. If there are several design alternatives being considered, the TS&O study will analyze the performance of each alternative under future conditions and use the results of this analysis to recommend the most attractive design alternative. This template is meant to aid consultants and other parties submitting work to MoDOT in their production of TS&O reports.




[[Category:905 Traffic Studies]]