2019 VERSION: Volume III: Guidelines for Applying Traffic Microsimulation Modeling Software 2019 Update to the 2004 Version

2004 Version - 3.0 Base Model Development

This chapter provides general guidance on the procedures for developing a microsimulation model. There are many software programs for performing this task and each has its own unique coding methodology. The guidance provided here is intended to give general advice on model development; however, the analyst should consult the specific microsimulation software documentation for information on available data input tools and techniques.

Building a model is analogous to building a house. You begin with a blueprint and then you build each element in sequence -- the foundation, the frame, the roof, the utilities and drywall, and finally the interior details. The development of a successful simulation model is similar in that you must begin with a blueprint (the link-node diagram) and then you proceed to build the model in sequence -- coding links and nodes, filling in the link geometries, adding traffic control data at appropriate nodes, coding travel demand data, adding traveler behavior data, and finally selecting the model run control parameters.

3.1 Link-Node Diagram: Model Blueprint

The link-node diagram is the blueprint for constructing the microsimulation model. The diagram identifies which streets and highways will be included in the model and how they will be represented. An example link-node diagram is shown in Figure 4. This step is critical and the modeler should always prepare a link-node diagram for a project of major complexity.

Figure 4. Example of link-node diagram.

The link-node diagram can be created directly in the microsimulation software or offline using various types of computer-aided design (CAD) software. If the diagram is created in the microsimulation software, then it is helpful to import a map or aerial photograph into the software over which the link-node diagram can be overlaid. If the diagram is created offline using CAD software, then it is helpful to import a map or photograph into the CAD software.

Nodes are the intersection of two or more links. Nodes are usually placed in the model using x-y coordinates and they can be at a place that represents an intersection or a location where there is a change in the link geometry. Some simulation software may also warrant consideration of a z coordinate. The node locations can be obtained from aerial photographs, maps, or physical measurements.

Links are one-directional segments of surface streets or freeways.²⁴  Links represent the length of the segment and usually contain data on the geometric characteristics of the road or highway between the nodes. Ideally, a link represents a roadway segment with uniform geometry and traffic operation conditions.²⁵

The analyst should consider establishing a node-numbering scheme to facilitate error checking and the aggregation of performance statistics for groups of links related to a specific facility or facility type (see Table 3 for an example of a node-numbering scheme designed to enable the rapid determination of the facility type in text output). Much of the output produced by microsimulation software is text, with the results identified by the node numbers at the beginning and end points of each link. A node-numbering convention can greatly facilitate the search for results in the massive text files commonly produced by simulation software.²⁶

Table 3. Example node-numbering convention.

If the link-node diagram was created offline (using some other software besides the microsimulation software), then the information in the diagram needs to be entered (or imported) into the microsimulation software. The x-y coordinates and identification numbers of the nodes (plus any feature points needed to represent link curvature) are entered. The nodes are then connected together to develop the link-node framework for the model.

3.2 Link Geometry Data

Once the modeler has completed coding the link-node diagram, then the modeler must input the physical and operational characteristics of the links into the model. This phase is when the modeler must code the following:

• Number of lanes.
• Lane width.
• Link length.
• Grade.
• Curvature.
• Pavement conditions (dry, wet, etc.).
• Sight distance.
• Bus stop locations.
• Crosswalks and other pedestrian facilities.
• Bicycle lanes/paths.
• Others.

The specific data to be coded for the links will vary according to the microsimulation software.

3.3 Traffic Control Data at Intersections and Junctions

Most microsimulation uses a time-step simulation to describe traffic operations (which is usually 1 s or less). Vehicles are moved according to car-following logic in response to traffic control devices and in response to other demands. Traffic control devices for microsimulation models will vary. Listed below are some examples:

• No control.
• Yield signs.
• Stop signs.
• Signals (pretimed, actuated, real-time traffic adaptive).
• Ramp metering.

3.4 Traffic Operations and Management Data for Links

Traffic operations and management data for links consist of the following:

• Warning data (incidents, lane drops, exits, etc.).
• Regulatory data (speed limits, variable speed limits, high-occupancy vehicles (HOVs), high-occupancy toll (HOT), detours, lane channelizations, lane use, etc.).
• Information (guidance) data (dynamic message signs and roadside beacons).
• Surveillance detectors (type and location).

3.5 Traffic Demand Data

Traffic demands are defined as the number of vehicles and the percentage of vehicles of each type that wish to traverse the study area during the simulation time period. Furthermore, it may be necessary to reflect the variation in demand throughout the simulation time period. In most software programs, the traffic entering into the network is usually defined by some parameter, and traffic leaving the network is usually computed based on parameters internal to the network (turning movements, etc.). The modeler must code the traffic volume by first starting from the external nodes (this is where the traffic is put into the model). Once all of the entering traffic volumes at the external nodes are coded, the modeler will then go into the model and define the turning movements and any other parameter related to route choice. The key traffic demand data are:

• Entry volumes by vehicle type and turning fractions at all intersections or junctions (random walk simulators).
• O-D/path-specific and vehicle data (path-specific simulators).
• Bus operations (routes and headways/schedules).
• Bicycle and pedestrian demand data.

3.6 Driver Behavior Data

Default values for driver behavior data are usually provided with the microsimulation software. Users may override the default values of any driver behavior parameters if valid observed data are available (e.g., desired free-flow speed, discharge headway, startup lost time at intersections, etc.). Driver behavior data include:

• Driver's aggressiveness (for minimum headway in car-following, gap acceptance for lane changing, response to yellow interval).
• Availability of (real-time) information for the driver.
• Driver's response to information (for pretrip planning and/or en route switching).

3.7 Events/Scenarios Data

Events data include:

• Blockages and incidents.
• Work zones.
• Parking activity in curb lane.

This data is optional and will vary according to the specific application being developed by the analyst.

3.8 Simulation Run Control Data

All simulation software contain run control parameters to enable the modeler to customize the software operation for their specific modeling needs. These parameters will vary between software programs. They generally include:

• Length of simulation time.
• Selected MOEs or output (e.g., reports, animation files, or both).
• Resolution of simulation results (e.g., temporal and special resolution).
• Other system parameters to run the model.

3.9 Coding Techniques for Complex Situations

Microsimulation software allows the modeler to develop a model to represent the real-world situation. However, not all possible real-world situations were necessarily contemplated when the software was originally written. This is when the modeler, with a good understanding of the operation of the software, can "extend" the software to simulate conditions not originally incorporated into the microsimulation software. However, this should only be attempted after the tools, resources, and skills available are fully appreciated. This is because new tools continue to become available that account for selected real-world situations.

Provided below are some examples of how basic microsimulation software can be applied to less standard situations, noting that calibration (discussed in chapter 5.0) must also consider the following situations:

• A curb lane is heavily used for parking, loading, and unloading activities. As a result, this lane may be blocked virtually all of the time. If the simulation software cannot correctly replicate the real situation, the modeler may consider removing this lane from the link.
• There is a drawbridge in the real-world network; however, the software does not have explicit "drawbridge" modeling capability. If boat traffic is very heavy and is equivalent to vehicular traffic, the modeler may consider coding the drawbridge as an intersection with fixed-time signal control. If boat traffic is irregular, the analyst might consider coding the drawbridge as a semi-actuated traffic signal-controlled intersection. If boat traffic is rare, then the drawbridge might be coded as a link with events that result in a 100-percent capacity loss with a certain probability of occurrence during the analytical period.
• Traffic regularly backs up on a freeway off-ramp, backing up onto the freeway. However, instead of stopping on the freeway and blocking a lane, the queue forms on the shoulder of the freeway, keeping the right-hand lane open. If this is the case in the study area, the modeler may artificially extend the off-ramp length to realistically model the traffic in the field.

3.10 Quality Assurance/Quality Control (QA/QC) Plan

Once the modeler is satisfied that the model is coded, the modeler must then vet the model for completeness. This could be a QA/QC process. Many of the models input are developed in a format that can be exported to a spreadsheet format. Therefore, the modeler can use this type of tool to aid in vetting the model for completeness and accuracy. The next chapter on error checking describes quality control tests in more detail.

3.11 Example Problem: Base Model Development

Continuing with the same example problem from the previous chapters, the task is now to code the base model.

The first step is to code the link-node diagram. How this is best done can be determined from the software user's guide. Figure 5 shows the link-node diagram for the example problem.

Figure 5. Link-node diagram for example problem.

The next steps are to input:

1. Link geometry data.
2. Intersection traffic control data.
3. Traffic operations and management data.
4. Traffic count data.
5. Run control parameters.²⁷