Guidance on The Level of Effort Required to Conduct Traffic Analysis Using Microsimulation

CHAPTER 3.  PROJECT SCOPE

This chapter provides guidance on how to develop a traffic simulation project scope. It includes a sample template to develop a microsimulation scope and provides guidance on how to develop an analysis plan. Interested agencies can use this chapter to develop RFPs for microsimulation analysis projects and analysis plans.

The following signs indicate that a traffic analysis project is on track and likely to be successful:

• The purpose of the analysis is clear.
  
  
• Key stakeholders are engaged throughout the analysis.
  
  
• A detailed analysis plan is prepared that identifies appropriate tools, data required, performance measures, and people responsible for various parts of the analysis both at the agency and consultant levels.
  
  
• Tools used in the analysis can convincingly demonstrate their ability to replicate observed traffic conditions using quality checked, internally consistent observed data.
  
  
• Interim and final results can be independently reproduced.
  
  
• Analytical results can be clearly communicated relative to analytical objectives.

A clear scope helps to avoid problems such as the following:

• Misunderstandings or ambiguities regarding the goals of the modeling effort.
  
  
• Mission creep such as unplanned enlargement of the study area or implemented advanced model features that were not originally part of the scope.
  
  
• Misapplication of the model (i.e., attempting to use the model at a level of detail for which it was not intended).
  
  
• Inappropriate sequencing of activities (e.g., starting to model “build” scenarios before the base model has been properly calibrated).

GUIDANCE ON DEVELOPING MICROSIMULATION SCOPE

The purpose of this section is to provide guidance on how to develop a microsimulation scope including developing the purpose and need for the analysis, determining the analytical approach and tools to be utilized, identifying and communicating data needs, identifying the performance measures to evaluate alternatives, and informing decisionmakers on the parameters of the analysis (i.e., what the analysis will and will not answer).

Project Understanding and Purpose

The project understanding should describe the purpose of the project, provide the project background, and present the problems and issues that the microsimulation analysis is intended to address. The project understanding should include clear descriptions of the following:

• The transportation project purpose and need.
  
  
• Elements that relate to the transportation problem to be analyzed.
  
  
• The project study area.
  
  
• Affected communities and stakeholders.
  
  
• Traffic analysis objectives and hypotheses.

Technical Approach

This section outlines the technical tasks necessary to accomplish the analytical objectives of the project. The technical approach should provide detailed information on the requirements of the analysis, the alternatives to be analyzed, and the performance measures needed to evaluate the alternatives.

Analysis Requirements

This section includes the following components that help define the analysis:

• Study area and facility types: The spatial extent of the study area includes any intersections, highways, and other facilities that are analyzed. The study area must cover beyond the end of the full spatial extent of queues and congestion in the baseline and future years of analysis.
  
  
• Analysis time period: The project analysis time period should be defined (e.g., morning/ afternoon peak hour and/or peak period, off-peak period, etc.). The analysis time period must cover the beginning and end of full temporal extent of queues and congestion in the baseline and future years of analysis. In some cases, the simulation analysis period must allow for vehicle loading and unloading time beyond the limits of the peak periods.
  
  
• Scenario definition: Scenarios should include geometric and operational alternatives that are analyzed and compared to the baselines. Chapter 7 in this report describes alternatives analysis.
  
  
• Analytical tool selection: Selection of the appropriate simulation tool is an important part of the study. The Analysis Plan section in this chapter provides specific guidance for this step.

Data Requirements

The data requirements for the development and calibration of a microsimulation model vary depending on the software package selected; however, they all require the following basic inputs:

• Roadway geometry.
  
  
• Traffic control data.
  
  
• Travel demand, traffic volumes, and intersection turning movements.
  
  
• Performance data (i.e., queue locations, queue lengths, travel times, and speeds).
  
  
• Data on vehicle characteristics (i.e., vehicle classification and vehicle mix).

Baseline Model Development

Most models are coded from georeferenced aerial photographs or as-built drawings. Reviewing previously developed models for the area is also a good starting point to determine a baseline. The following attributes are typically coded in the model:

• Number of lanes.
  
  
• Link/lane width and length.
  
  
• Grades.
  
  
• Curvature.
  
  
• Sight distances.
  
  
• Bus stop locations.
  
  
• Crosswalk and pedestrian facilities.

In coordination with the development of the base year microsimulation model, the TDM (if utilized) should be refined to reflect the zonal structure of the microsimulation model being developed. Most TDM software contains procedures for extracting or zooming in on a subarea for analysis. This procedure allows for the analyst to include all of the regional factors that may affect travel in the analysis area while working with a smaller subarea model. The subarea model zonal structure should be developed to correspond to the zonal structure of the microsimulation model. If the TDM has a 24-h O-D trip table in conjunction with a proper data collection program, the O-D table can be refined by developing factors to split the trip table into smaller time periods.

Baseline Model Calibration

Calibration of the baseline model is crucial to the validity of the model to replicate existing observed conditions as well as its stability to forecast future operations. Calibration requires two steps: (1) calibration for capacity and (2) calibration for route choice. This methodology is described in Traffic Analysis Toolbox Volume III: Guidelines for Applying Traffic Microsimulation Modeling Software.⁽¹⁾ Prior to calibration, criteria must be developed for the models that are being calibrated. Model calibration targets should be set after taking into account the performance measures developed and the quality of field data. The performance measures should be measurable in terms of the field data collected and can be calculated for real-life conditions and compared to the model outputs.

Development of the Future Baseline Model

A future baseline microsimulation model (or future no-build alternative) is an essential part of the analysis process; it is the basis for comparison between alternatives. Many microsimulation models are used because the macroscopic deterministic analytical techniques do not fully capture the extent of congestion.

A common methodology for developing future demand forecasts is using a regional TDM. TDMs take into account regional growth due to land use, demographics, and socioeconomic activity. In cases where a TDM does not exist, it is acceptable to utilize a trend projection of travel demand. As with the development of the existing base-year model, the future baseline (i.e., no build) microsimulation model and future baseline subarea TDM should have zone and link/node structures that ensure correspondence between the models.

The amount of further refinement to the zonal layers within the demand and simulation models depends on the type of growth anticipated in the study area and the future no-build transportation system. The zones need to be refined if there is a large shift in land use within the study area or if transportation improvements cause a shift in land use or become barriers to access to the transportation system from certain zones. Otherwise, the future baseline scenario zones for the simulation model and the demand model can remain the same as the existing baseline zonal systems.

Alternatives Analysis

The alternatives analysis consists of the following steps:

• Development of project alternatives for analysis: Alternatives are usually developed by the project team and are shaped through the stakeholder involvement process.
  
  
• Model application: Microsimulation models operate based on randomly generated numbers, and results can often vary from model run to model run of the same scenario. Therefore, it is necessary to run each scenario multiple times with different random number seeds to determine mean, minimum, and maximum conditions. Multiple model runs are also useful in estimating the reliability of travel time associated with particular alternatives.
  
  
• Tabulation of results: The output of microsimulation models is usually in the form of animation and numerical outputs. These outputs are based on performance measures established at the beginning of the project and are used to compare system performance between alternatives and the baseline and across alternatives. Animation allows for visualization of the movement of individual vehicles through the network.
  
  
• Analysis of alternatives: The analysis of the alternatives is performed by analyzing the comparison of the no-build scenario results to the alternative scenario results.

Final Report and Presentations

The final report should summarize the efforts, methodologies, assumptions, and results of the study. The report’s target audience is key decisionmakers and stakeholders who decide on the funding and implementation of the improvements put forth in the alternatives testing. Therefore, it is important to interpret the technical content and tabular results. The development of the model should not be the subject of the final report; this information can be presented in technical appendices to allow other analysts and modelers to view the technical information and technical analysis that went into the study.

A typical outline for the final report includes the following:

• Study objectives.
  
  
• Study methodology.
  
  
• Data collection.
  
  
• Model calibration.
  
  
• Forecasting procedures.
  
  
• Alternatives analysis.
  
  
• Summary of results.

Presentation of the final results of the study can be accompanied by the animations produced as an output of the model runs.

Project Deliverables

Clear project deliverables should be listed at the end of each task in the scope of work. Deliverables should include all meetings, project status reports, data to be compiled and delivered, models to be delivered, and reports including the number of copies.

Project Schedule

The project schedule should identify the expected duration of the overall project as well as the expected duration of individual interim tasks. The schedule should also provide milestones, meetings, and presentations.

Labor-Hour and Cost Estimate

In preparation for the RFP, the agency should consider developing a labor-hour and cost estimate for the project so adequate resources can be allocated to meet the project requirements. The estimate should contain enough detail not only to communicate the dollar value expenditure allocated for consulting services, but also the resources that will be needed by the agency to conduct and manage the project.

SAMPLE MICROSIMULATION SOLICITATION TEMPLATE OUTLINE

This section provides a sample microsimulation solicitation template outline.

1. RFP Cover Page
   • Agency title.
   • Project title.
   • Dated cover letter. Provide a cover letter inviting the contractor firms to propose on the RFP.
     
     
2. Introduction/Overview
   • Project description and purpose. Name the agency/agencies that will overlook the project. Provide a detailed description of the project and its purpose.
     
     
3. Submittal Information
   • Contact. Provide the project manager’s and contracts officer’s names, telephone numbers, e‑mail addresses, and mailing addresses.
   • Key action dates. Provide dates for the pre-bid meeting, questions deadline, proposal deadline, interview, and decision.
   • Proposal format and content. Provide the sections and format for the proposal.
     
     
4. Scope of Work
   • Project definition and requirements.
     • Study area. Define the spatial extent of the study area, including intersections, highways, and corridors.
     • Analysis time period. Define the analysis period and simulation period. For example, while the project analysis might be for the morning and afternoon 3-h peak periods of congestion, the simulation period used must provide for warm-up/initializing traffic and for processing residual queues resulting from the peak hour. The analysis time period must cover the full temporal extent of queues in the baseline and future years of analysis.
     • Scenario definition (morning, afternoon, baseline, future year, etc.). Provide the time periods and scenarios that should be processed for the project. Scenarios should include geometric and operational alternatives to be analyzed and whether they are to be analyzed independently or in packages.
     • Simulation runs per scenario. Provide/reference the methodology to determine the number of model runs for each scenario that the contractor must simulate.
     • Modal impacts. Provide travel modes that must be evaluated for the project. Examples include single-occupancy vehicle, HOV, bus, light rail, truck, etc.
     • Performance measures. Define the performance measures to be produced by the analysis. Typical performance measures include speed, travel time, reliability of travel time, volume, travel distance, vehicle miles traveled per passenger miles traveled, vehicle hours traveled per passenger hours traveled, delay, queue lengths, number of stops, crashes and their duration, emissions, fuel consumption, and benefit/‌cost. These should be produced for the whole study area and analysis period by facility type, region, mode, and scenario.
       
       
   • Work task description.
     • Project management.
     • Data collection.
     • Base model development and calibration criteria and requirements.
     • Future year forecast and future baseline scenario.
     • Alternatives analysis.
     • Deliverables (report and presentations).
       
       
   • Project budget and schedule. Provide the total budget and schedule for the project. RFPs should be submitted with a proposed budget for each task by person, including hourly labor rates, overhead, fee, and direct expenses. RFPs should include a detailed schedule outlining tasks, subtasks, milestones, deliverables, and meetings.
     
     
5. Evaluation Criteria
   • Qualifications of project manager, including experience/expertise.
   • Management approach and quality assurance process.
   • Project team qualifications.
     • Staff expertise. Demonstrated ability based on firm’s and team’s experience to conduct the work.
     • Staff resources. Depth and breadth of staff resources.
     • Location familiarity. Familiarity of key staff with study area travel and congestion patterns, as well as agencies and organizations involved with transportation in the region.
     • Presentation skills. Ability to convey results of analyses in written form and present findings that are understandable to nontechnical audiences.
       
       
6. Contract Requirements
   • Disadvantaged business enterprise policy.
   • Insurance requirements.
   • Selection dispute. Provide a description of criteria, process, and date that a proposer must follow for disputing the selection.
     
     
7. Addendums

THE ANALYSIS PLAN

Developing an analysis plan is an important first step in any transportation analysis project. This section discusses developing an analysis plan.

Determine Overall Project Scope

Confusion about the goals, objectives, or physical boundaries of a microsimulation project can cause delays and/or conflicts among stakeholders. At the beginning of a project, the analysis managers should develop an initial understanding of the analysis objectives. Several critical tasks need to be performed to gain this understanding prior to engaging stakeholders and moving forward with the analysis process. The outputs from this exploration should be considered preliminary and subject to change based on the input and feedback from stakeholders at the project kickoff meeting. These tasks include the following:

• Develop an outline for the analysis plan. The analysis managers should define an outline for the analysis plan early on in the analysis process. Elements to include in the outline vary depending on the input from the stakeholders and the needs of the analysis; however, several common elements should be included in all effective analysis plans including the following:
  
  
  •  Introduction.
    
    
    • Project purpose.
      
      
    • Project background.
      
      
    • Study area overview.
      
      
    • Process for developing and applying the analysis plan.
      
      
  • Study area description, existing traffic conditions, and available data.
    
    
  • Analysis methodology and modeling approach.
    
    
  • Analysis scenarios and mitigation strategies.
    
    
  • Data requirements.
    
    
  • Output performance measures.
    
    
  • Criteria and data requirements for model calibration.
    
    
  • Analysis budget and resources.
    
    
  • Analysis schedule.
    
    
  • Allocation of responsibilities.
    
    
• Determine project objectives and needs. This task serves to clearly determine the “what” and “why” for conducting the analysis. The overall goals and objectives for the mitigation strategies should be assessed and used to shape the goals and objectives for the analysis effort. The analysis objectives should fully support and be consistent with the overall goals for the deployment project.
  
  
• Identify stakeholders. A broad set of stakeholders should be identified to fully represent the agencies and organizations impacted by the project.
  
  
• Understand the study area, including major transportation issues and mitigation strategies to be considered. Available documentation should be compiled and reviewed by project managers to familiarize themselves with the operating characteristics of the study area and identify substantial issues. Individual interviews with project partners also can be helpful in understanding study area conditions and the strategies being considered. Previous studies, archived data systems, and accident/incident data reports can all provide valuable insight into the current operational characteristics of the study area. The project managers should also seek out information on the mitigation strategies being considered and the impact these strategies have had in other regions.
  
  
• Conduct a site visit. The analysis managers should visit the study area to gain a better understanding of traffic conditions and characteristics. The site visit should include a comprehensive review of all the different facilities, modes of transportation, and major mode transfer locations throughout the study area. The site visit may also include visits to the regional traffic management center or toll authority, as appropriate. Also, depending on the characteristics of the mitigation strategies being considered, the project managers may want to plan to visit the site on multiple occasions (e.g., peak period versus off-peak or good weather versus inclement weather) to gain further insight into how traffic characteristics vary.
  
  
• Schedule a technical kickoff meeting. Once the project managers gain an initial understanding of the project and analysis needs, a technical kickoff meeting should be scheduled and conducted to discuss the analysis methods. Agency stakeholders should be encouraged to attend. The project managers should be prepared to provide a presentation documenting their initial understanding of the project and the analysis plan outline. The presentation will be used to solicit feedback from the stakeholders during the meeting in order to adjust the analysis managers’ understanding to more closely match project expectations. Copies of this presentation should be provided to all stakeholders as initial documentation of project understanding. The intended outcomes of the kickoff meeting include the following:
  
  
  • Confirm stakeholder perceptions of project needs. The kickoff meeting provides an opportunity for the project managers to gain consensus on expectations for both the deployment as well as the necessary analysis.
    
    
  • Confirm analysis scope. Scope issues to be explored with stakeholders include the following:
    
    
    • What is the appropriate geographic scope for the analysis?
      
      
    • What facility types need to be included in the analysis?
      
      
    • What travel modes need to be included in the analysis?
      
      
    • What are the possible mitigation strategies to be implemented?
      
      
    • What are the expected traveler responses to the mitigation strategies?
      
      
    • What performance measures need to be produced by the analysis and what are acceptable performance levels?
      
      
    • What is the approximate budget and schedule for the analysis work?
      
      
  • Confirm scenarios to be used in the analysis. It is critical to understand precisely when (i.e., under what conditions) the mitigation strategies will be applied and how their application may vary under different conditions. The project managers and stakeholders need to identify the combinations of travel demand, incidents, special events, and weather events that comprise corridor operations.
    
    
  • Discuss data availability. Analysis managers and stakeholders should explore potential data sources for the study. The quality and amount of data (sample sizes) for each performance measure to be utilized should also be evaluated. Chapters 4 and 6 of this report provide discussions on sample sizes of the field data needed. This discussion should include both traditional and nontraditional data sources in order to compile a comprehensive set of data that may be available for the project. For analysis needs, archived automated data sources (e.g., traffic detectors) are often more desirable sources of data than manually collected data. The long-term availability of automated data representing different operational conditions (e.g., varying demand, incident, and weather conditions) provides an opportunity to effectively assess multiple operating conditions. Data from multiple sources must also be for concurrent time periods. The data should be collected from all sources for the same period. For each data source, the analysis managers should ascertain the following:
    
    
    • Time periods when the data are available.
      
      
    • The format of the data.
      
      
    • Any lag time in data availability (e.g., is accident data available immediately or is time required to request, acquire, and record the data into a common database?).
      
      
    • Reliability of the data sources (e.g., are there significant gaps in the data?).
      
      
    • Any known data quality issues (e.g., are there any operating conditions that cause the data to be inconsistent?).
      
      
• Update analysis plan. Analysts should begin populating the analysis plan outline based on the information obtained during the kickoff meeting.
  
  

Select/Determine Analysis Methodology

Following the kickoff meeting, the analysis managers should begin to explore and select the appropriate analysis methodology to be applied. This is a critical step because the selection of the appropriate methodology and tools ensures that the analysis meets the needs of the study and streamlines the analysis process. Key steps in the evaluation and selection of the analysis methodology include the following:

• Research and identify available analysis tools for the study area. The analysis manager should research and compile information on models and analysis methodologies currently used in the region. This may include models that are used on a continual basis in the region (e.g., the regional TDM) as well as individual models that are used for specific one-time-only analysis in or near the study area. For each model or tool, the analysis manager should identify the following:
  
  
  • The analysis package or tool (i.e., name and version of the software).
    
    
  • The year of the analysis.
    
    
  • The year the data sources were collected along with type and location.
    
    
  • The time periods targeted for analysis.
    
    
  • The model geographic limits.
    
    
  • Facilities represented in the model.
    
    
  • Modes represented in the model.
    
    
  • Any special scenarios available in the model (e.g., incidents, special events, weather, etc.).
    
    
  • High-level assessment of model capabilities and limitations.
    
    
  The availability or popularity of a model or tool in a region should not be the sole determinant for selecting the models and methodologies used in the analysis. In subsequent steps, the analysis project managers will assess their individual needs and map these to an appropriate tool or combination of integrated tools. It may be determined that the capabilities of the existing tools in the region are not sufficient to meet the needs of the analysis and a new methodology must be developed. However, this information on available tools is useful in selecting the appropriate methodology and identifying potential data sources for the model development.
  
  
• Identify factors for selecting methodology. The analysis managers should perform a critical analysis of project factors to determine the required robustness of the analysis methodology selected. This information will be used in a subsequent step to map needs to an appropriate tool, or combination of tools, using a decision support tool developed by USDOT as part of the Traffic Analysis Tools initiative. To complete this process, the analysis managers should compile information related to the following factors:
  
  
  • Geographic scope.
    
    
  • Facility types impacted.
    
    
  • Travel modes impacted.
    
    
  • Any potential strategies considered.
    
    
  • Expected traveler responses.
    
    
  • Approximate budget and schedule.
    
    
• Determine performance measures. The last piece of information required to complete the selection of the methodology using the Traffic Analysis Toolbox is to identify required output performance measures.^(1,6,7) The identified performance measures should be closely tied to the identified project goals/objectives and the expected traveler impacts. An effective way to identify appropriate performance measures is to develop one or more specific hypotheses to be tested for each objective. These hypotheses can either indicate a change in traffic conditions (e.g., the mitigation strategies will reduce travel time by 5 percent) or can be neutral in the prediction of an impact (e.g., the mitigation strategies will not result in a change in corridor accident rates). Performance measures that support the testing of each formulated hypothesis should then be identified. Use of this method ensures that the performance measures are appropriately mapped to the project goals and objectives.
  
  
• Use FHWA criteria and methodology to select the appropriate traffic analysis tools. FHWA has developed a useful guide to help practitioners select an appropriate analysis tool based on a number of input factors. This guidance includes a report and an automated decision support tool.⁽⁹⁾ Figure 9 provides an overview of the basic factors to be considered using the FHWA guidance. In assessing the demanding needs of project analysis, it may be revealed that multiple tools are needed. A single tool may not be sufficiently robust to handle the analysis objectives, and the analysis managers may need to consider integrating the analysis capabilities from multiple tools to achieve the necessary abilities. Once appropriate tool categories have been selected by the decision support tool, the analysis manager can use the documentation provided in Traffic Analysis Toolbox Volume II: Decision Support Methodology for Selecting Traffic Analysis Tools to research the range and capabilities of individual software packages and tools within the selected category.⁽⁶⁾ The FHWA documentation includes links to individual research organizations and vendors supporting the various packages that can provide even more information.

 
Figure 9. Flowchart. Overview of analysis factors to be considered in selecting an analysis methodology/tool.⁽⁶⁾