• Federal Highway Administration >
• Publications >
• Research Publications >
• 10038 >
• 003.Cfm >
• Balancing Safety and Capacity in an Adaptive Signal Control System — Phase 1

Balancing Safety and Capacity in an Adaptive Signal Control System — Phase 1

3.0 ANALYSIS AND SIMULATION METHODOLOGIES

This section describes the research team's approach to analyzing the various relationships between signal timing parameters and surrogate measures of intersection safety. Details of the SSAM methodology and processing tools are described to provide further context of the analysis effort.

The analysis and simulation methodology followed three steps. First, each test scenario—a combination of traffic conditions and signal timing parameters—was initially input and analyzed in Synchro™, a microscopic and deterministic signal timing optimization model. Based on the data entered for a specific case scenario, Synchro™ was used to either evaluate the test scenario conditions (i.e., compute traffic efficiency performance) and/or to optimize the signal timing settings. Next, the results from the Synchro™ analysis were transferred to VISSIM^®, a microscopic and stochastic traffic simulation model. This step was time consuming both in the transfer mode from Synchro™ as well as in having to run the simulations for multiple replications. Nevertheless, VISSIM^® was selected as the preferred model due to its ability to represent comprehensive signal timing logic and its resolution of vehicle trajectory data at 1/10 s. Six simulation runs were performed in VISSIM^® for each test case before the vehicle trajectory data were transferred to the FHWA SSAM analysis software. The last step was to summarize the surrogate measures and to test for statistical significance using the t-test method embedded in SSAM. Each iteration of the simulation consisted of 15 min of warm-up period followed with a full hour of simulation time during which the safety performance measures were calculated. Data from the warm-up period were ignored during the analysis.

The choice to use only these three models in this project was based on the research team's knowledge of each model, its ease of use, the model's credibility, and its application to this research. Synchro™ is one of the most commonly used models in the United States for signal timing optimization and evaluation. It is very easy to use to develop several signal timing alternatives. Moreover, the research team is experienced in using Synchro™.

VISSIM^® was used because of its ability to provide the data resolution that would support SSAM and to output phase timing performance data, including the cumulative number of green and red durations as well as the mean and average green and red times for each signal group (phase) in a file with the extension .lzv. VISSIM^® has a large user base and is well supported in the United States. Compared to models such as CORSIM and SimTraffic^®, VISSIM^® is not easy to use and migration of data from Synchro™ to VISSIM^® was very tasking and time consuming. The task of migrating data from the various Synchro™ signal timing alternatives was the most inefficient process of the research.

SSAM is very easy to use and provides the surrogate measures of safety necessary for comparing alternative signal timing scenarios. Each simulation run in VISSIM^® results in a corresponding trajectory file (.trj). SSAM analyzes the batch of VISSIM^® trajectory files to identify conflict events and catalogs a variety of event data including, but not limited to, the following surrogate measures of safety: TTC, PET, DR, maximum deceleration rate (MaxD), maximum speed of either vehicle (MaxS), and maximum speed differential of the two vehicles (DeltaS).

TTC is the time to crash into the leading vehicle if the following vehicle does not react by taking an evasive maneuver, assuming constant speeds. PET is the time that the following vehicle actually arrives at the point corresponding to a particular calculation of TTC after taking into account that the following vehicle has reacted to the leading vehicle's movements by braking.

When TTC = 0 and/or PET = 0, SSAM determines that a crash has occurred. If TTC > 0, TTC ≤ 1.5 s, and PET ≤ 5.0 s, then SSAM marks the event as a conflict. The 1.5-s TTC threshold and 5.0-s PET threshold are defaults in the SSAM software as recommended by the literature and testing during previous projects.^(5,6)

3.1 SYNCHRO™

Synchro™ (developed by Trafficware^®, Inc.) is a software package capable of modeling signalized and unsignalized intersections.⁽¹²⁾ Synchro™ is commonly used for intersection-capacity and level-of-service analysis and/or signal timing optimization. The software has the ability to compute optimum timings for intersection offsets, cycle lengths, phase splits, and phase sequence. The software can display time-space diagrams that illustrate vehicle progression through a network. Since Synchro™ performs its analysis at a platoon level instead of an individual level, it is characterized as a macroscopic simulation model. Synchro™ version 6.0 was used to code the various alternative scenario models and optimize the signal timings in this project.

3.2 VISSIM^®

VISSIM^® is a time-step and behavior-based microscopic traffic simulation software.⁽¹³⁾ It is characterized as microscopic simulation software because of its ability to model and analyze each entity of the network at an individual level. VISSIM^® is capable of simulating multiple modes of traffic, including cars, heavy-goods vehicles, high-occupancy vehicles, bus transit, light rail, heavy rail, rapid transit, cyclists, and pedestrians, for urban as well as rural conditions.

The VISSIM^® model consists internally of two distinct components, the traffic simulator and the signal state generator. These components are constantly communicating detector calls and signal status to each other through an interface. The traffic simulator is a microscopic traffic flow simulation model including car following, lane changing, and gap acceptance logic. The signal state generator is signal-control software that polls detector information from the traffic simulator on a discrete time-step basis (1/10 s). It then determines the signal status for the following time-step and returns this information to the traffic simulator. This interaction is the driving force behind modeling a signalized intersection.

VISSIM^® version 5.10 release 7 was utilized in this project to code the alternative scenarios and collect the vehicle trajectory data.

3.3 SSAM

3.3.1 Overview

SSAM combines microsimulation and automated conflict analysis to analyze the frequency and character of narrowly averted vehicle-to-vehicle collisions (conflicts) to compute surrogate measures of the safety of traffic facilities. SSAM determines and quantifies three types of conflicts: crossing (angle), lane changing, and rear end.⁽⁵⁾

SSAM provides the following features:

• A table of all conflicts identified in the batch of analyzed .trj files, including file, time, location, vehicle identifications, and several measures of conflict severity.

• A summary of conflict counts by type and file, with average values of surrogate measures over all conflicts.

• A filtering mechanism that allows the isolation of subsets of conflicts by ranges of surrogate measures of safety, conflict type, network link, or a rectangular region of the network.

• A facility for statistical comparisons of the conflict frequencies and values of surrogate measures of safety for two alternative cases using Student's t-distribution for hypothesis testing.

• A display of the location of conflicts on the network map, with icons of different shapes and colors assignable to different conflict types or severities as shown in figure 1.

Figure 1. Screenshot. SSAM's color-coded conflicts.

3.3.2 Description of the SSAM Process

This section, extracted from the SSAM validation report and user manual, provides an overview of the typical workflow using the SSAM software, tracing the flow of information through various input data, tasks or operations, and resulting outputs.^(6,14) In doing so, many of the screens of the SSAM graphical user interface are introduced. SSAM operates by processing data describing the trajectories of vehicles driving through a traffic facility (e.g., a signalized intersection) and identifying conflicts. The vehicle trajectory input data for SSAM are generated by traffic simulation software in a trajectory file format (using a .trj file extension) specially designed for SSAM. SSAM calculates surrogate measures of safety corresponding to each vehicle-to-vehicle interaction and determines whether or not each interaction satisfies the criteria to be deemed an official conflict. A table of all identified conflicts and their corresponding surrogate measures of safety is summarized as an output of SSAM. Figure 2 illustrates the workflow for using SSAM.

Figure 2. Chart. Operational concept of SSAM.⁽⁶⁾

The user begins the analysis by first enabling output of vehicle interaction (trajectory) data in the simulation model of his or her choice. The traffic engineer then runs the simulation model for a number of iterations—replications with alternate random number seeds—to obtain a statistically sufficient set of simulation output data. The user then launches the standalone SSAM application.

The user defines a new conflict analysis case by using the menus to create a new case file or, alternatively, to open an existing case file. The software uses two threshold values for surrogate measures of safety to delineate which vehicle-to-vehicle interactions are classified as conflicts. These two thresholds are applied to the values TTC and PET. The software provides default threshold values for these measures, which the analyst may override with his or her preferred alternate values. SSAM utilizes a default TTC value of 1.5 s, as suggested in previous research. Once the conflict identification thresholds are determined, the user processes the simulation (trajectory) data to identify vehicle-to-vehicle interactions that satisfy the conflict classification criteria. Each conflict identified during analysis, including data from the trajectory files of all corresponding replications of the simulation, is listed with conflict details, including the time, location, and all surrogate measures of safety for that conflict.

The algorithms used by SSAM to identify conflicts to be processed from the vehicle trajectory files are time intensive depending on the size of the .trj file, which is a function of the number of vehicles in the network model and the amount of time simulated. A high-end computer might require more than 10 min to process data from 5 h of traffic for a single intersection model. Large multi-intersection networks might require hours of processing time. The following steps summarize the technique used to identify conflicts:

Step 1: Determine the dimensions of the analysis area based on the header name in the .trj file. These dimensions define the width and height of a rectangular analysis area and indicate if trajectory data are provided in English or metric units. SSAM constructs a zone grid to cover the entire rectangular analysis area, as shown in figure 3. Individual square zones cover 50-ft by 50 ft areas. By dividing the region into these zones, the number of vehicle-to-vehicle comparisons necessary to identify potential conflicts is reduced considerably.

Figure 3. Illustration. SSAM's zone grid⁽⁶⁾

Step 2: Analyze a single time-step of a trajectory file. For each vehicle in the analysis region, SSAM projects that vehicle's expected location as a function of its current speed if it were to continue traveling along its path for up to the duration of the configured TTC value. A vehicle's projected path is based on a look ahead over the next 10 s of trajectory data. The path, as shown in figure 4, is a set of straight line segments (labeled S) connecting the vehicle's future downstream locations (labeled X). The threshold TTC value is configured by the user of SSAM, typically with a threshold value of order of 1.5 s. Conflicts with TTC values larger than 1.5 s are not generally considered in the safety community to be severe enough events for recording in a traditional field conflict study.

Figure 4. Illustration. Vehicle path.⁽⁶⁾

The process of projecting the distance that a vehicle may progress forward during the specified look-ahead time interval and the calculation of the exact coordinates of that projected vehicle position occur as follows, assuming SSAM is going to analyze the conflicts for vehicle A at time t₁. First, SSAM extracts all data related with vehicle A from the trajectory file, such as vehicle A's location, speed, acceleration, etc., at time t1 and several time-steps after t₁. Each location is denoted as (x₁,y₁), (x₂,y₂), etc. Then, SSAM projects vehicle A's distance forward along its trajectory, defined by the following locations:

1. Each vehicle is defined as a polygon (rectangle) with four corner points (see Figure 5).

2. The forward distance that the vehicle will travel is calculated in the MaxTTC interval, denoted as DIS₁ = V₁ * MaxTTC (see Figure 5).

3. The vehicle's next time-step location (x₂,y₂) is calculated based on the distance from current location to that location, denoted as DIS₂ = |Location (t+1)-Location (t)| (see Figure 5).

4. If DIS₂ is less than DIS₁, then DIS₂ is subtracted from DIS₁ and the previous two calculations are repeated, updating DIS₁ = DIS₁-DIS₂ and DIS₂ = |Location (t+2)- Location (t+1)| and comparing the new DIS₁ and DIS₂.

Figure 5. Illustration. Conflict types by angle.⁽⁶⁾

Step 3: For each vehicle, calculate the rectangular perimeter delineating the location and orientation of that vehicle at its projected future position. Overlay that rectangle on the zone grid, calculating which rectangular zones in the grid will contain at least some portion of that vehicle. For each zone the vehicle will occupy, add that vehicle to a list of occupants maintained for each zone. Any time a vehicle is added into a zone that currently contains one or more other vehicles, check for overlap of the new vehicle (rectangle) with each of the other vehicles (rectangles) in that zone. It is possible that two vehicles may partially occupy the same zone without overlapping. However, two overlapping rectangles indicate that a future collision is projected for this pair of vehicles, and therefore, a potential conflict has been identified, as portrayed in Figure 6. SSAM maintains a list of all conflicting vehicle pairs (all conflict events) for the current time-step. For each time-step, the list is prepopulated with all conflicting vehicle pairs from the prior time-step. If the current vehicle being added to the zone grid overlaps with any other vehicle, that vehicle pair would be added to the conflict list for the current time-step, if not already in the list.

Figure 6. Illustration. Checking a conflict between two vehicles at MaxTTC.⁽⁶⁾

Step 4: Continue so that SSAM can perform more detailed processing of each conflicting vehicle pair in the list for the current time-step. First, update the TTC of the vehicle pair. This is done by iteratively shortening the future projection timeline by a tenth of second and reprojecting both vehicles over successively shorter distances until the pair of vehicles no longer overlaps in their projected locations. In this way, a more accurate TTC value is established for this time-step. This is portrayed in Figure 7, where the TTC values have reduced from the maxTTC value of 1.5 s (illustrated in Figure 6) to a TTC value of 1.3 s. Instead of the large overlap in Figure 6, the vehicles in Figure 7 have just barely come into contact. Note that if the projection timeline reduces to 0 s and the vehicles still overlap, this is a crash.

Figure 7. Illustration. Checking a conflict between two vehicles at TTC = 1.3 s (vehicles no longer in conflict).⁽⁶⁾

At this point, various surrogate measures of safety, such as the minTTC, taking the minimum of the current TTC value and that of the prior time-step, are calculated and updated. Also, the current (actual) positions of both vehicles are recorded for postencroachment analysis.

If it was found that the vehicle pair does not overlap over any projected time between zero and maxTTC, then this vehicle pair is in the conflict event list by virtue of being in the list during the prior time-step. In this case, the event remains in the list, watching for the trailing vehicle to eventually occupy, or encroach on, a position formerly held by the leading vehicle. The time differential between when the leading vehicle occupied this location and the trailing vehicle arrived is the PET. If a postencroachment was observed, then the minimum PET is updated, and this conflict event remains in the list, as the postencroachment could potentially reduce as the vehicle trajectories progress over time.

If a vehicle pair in the conflict event list is no longer on an imminent collision course and it is clear that PET to any prior positions could not further reduce the minimum PET or if the maximum PET has elapsed, then this vehicle pair is identified for removal from the conflict event list. Prior to removal, all final surrogate measures are computed, including conflict starting and ending points, conflict angles, minimum TTC, and the change between conflict velocity (DeltaV). Also, the conflict is classified at this time as a crossing, rear-end, and/or lane-change conflict. If this conflict event has ended, then the conflict and all surrogate measures are added to the conflict table, and the event is removed from the tracking list.

3.3.3 Definitions of Surrogate Measures Computed by SSAM

SSAM's user manual defines several surrogate measures as follows:⁽⁶⁾

• TTC is the minimum time-to-collision value observed during the conflict. This estimate is based on the current location, speed, and future trajectory of two vehicles at a given instant. A TTC value is defined for each time-step during the conflict event. A conflict event is concluded after the TTC value rises back above the critical threshold value. This value is recorded in seconds.

• PET is the minimum postencroachment time observed during the conflict. PET is the time between when the first vehicle last occupied a position and the time when the second vehicle subsequently arrived at the same position. A value of zero indicates a collision. PET is associated with each time-step during a conflict. A conflict event is concluded when the final PET value is recorded at the last location where a TTC value was still below the critical threshold value. This value is recorded in seconds.

• MaxS is the maximum speed of either vehicle throughout the conflict (i.e., while the TTC is less than the specified threshold). This value is expressed in feet per second or meters per second, depending on the units specified in the corresponding trajectory file.

• DeltaS is the difference in vehicle speeds as observed at tMinTTC. More precisely, this value is mathematically defined as the magnitude of the difference in vehicle velocities (or trajectories), such that if v1 and v2 are the velocity vectors of the first and second vehicles respectively, then DeltaS = || v1 - v2 ||. For context, consider an example where both vehicles are traveling at the same speed, v. If they are traveling in the same direction, DeltaS = 0. If they have a perpendicular crossing path, DeltaS = (√2)v. If they are approaching each other head on, DeltaS = 2v.

• DR is the initial deceleration rate of the second vehicle, recorded as the instantaneous acceleration rate. If the vehicle brakes (i.e., reacts), this is the first negative acceleration value observed during the conflict. If the vehicle does not decelerate, this is the lowest acceleration value observed during the conflict. This value is expressed in feet per second or meters per second, depending on the units specified in the corresponding trajectory file.

• MaxD is the maximum deceleration of the second vehicle, recorded as the minimum instantaneous acceleration rate observed during the conflict. A negative value indicates deceleration (braking or release of gas pedal). A positive value indicates that the vehicle did not decelerate during the conflict. This value is expressed in feet per second or meters per second, depending on the units specified in the corresponding trajectory file.

• ConflictType, as shown in Figure 8, describes whether the conflict is the result of a rear-end, lane-change, or crossing movement. If link and lane information is not available for both vehicles, then the event type is classified based solely on the absolute value of the ConflictAngle. The type is classified as a rear-end conflict if ||ConflictAngle|| < 30 degrees, a crossing conflict if ||ConflictAngle|| > 85 degrees, or otherwise a lane-change conflict. The simulation model that produced the vehicle trajectory data can generally provide link and lane information for both vehicles, though the coding of these values may vary significantly from one simulation vendor to the next.

  

  Figure 8. Illustration. Conflict types by angle.

  If link and lane information is available, that information is utilized for classification in the case that the vehicles both occupy the same lane of the same link at either the start or end of the conflict event. If the vehicles both occupy the same lane at the start and end of the event, then it is classified as a rear-end event. If either vehicle ends the conflict event in a different lane than it started without having changed links, then the event is classified as a lane-change conflict. If either of the vehicles changes links over the course of the event, then the conflict angle determines the classification as previously described, with the following possible exception.

  For two vehicles that begin the conflict event in the same lane, as shown in figure 9, but change links over the course of the event, the classification logic considers only rear-end or lane-change types, based on the conflict angle and using the threshold value previously mentioned. Note that vehicle maneuvers such as changing lanes into an adjacent turn-bay lane or entering into an intersection area may be considered changing links, depending on the underlying simulation model. In some cases, vehicles that appear to be traveling in the same lane may actually be considered by the simulation model as traveling on different links that happen to overlap.

  

  Figure 9. Illustration. Lane-change conflict.

• MaxDeltaV is the maximum DeltaV value of either vehicle in the conflict.

• FirstDeltaV (SecondDeltaV) is the change between conflict velocity (given by speed FirstVMinTTC and heading FirstHeading) and the post collision velocity (given by speed PostCrashV and heading PostCrashHeading). This is a surrogate for the severity of the conflict, calculated assuming a hypothetical collision of the two vehicles in the conflict.

3.3.4 SSAM Data Terms and Definitions

SSAM computes and records the following data or measures for each conflict identified in the vehicle-trajectory input data.⁽⁶⁾ This information is provided in the conflicts table on the conflicts panel. It is possible to filter out several of the conflicts based on specified ranges of these values using the Filter tool. These data may also be exported for use in other third-party processing software, such as Microsoft Excel^®, where more complicated analysis options may be available. The following are used in SSAM:

• tMinTTC is the simulation time when the minimum TTC value for this conflict was observed.

• xMinPET is the x-coordinate specifying the approximate location of the conflict at the time when the minimum PET was observed. More specifically, this location corresponds to the center of the first vehicle where the subsequent arrival of the second vehicle to the same location was the shortest encroachment observed.

• yMinPET is the y-coordinate specifying the approximate location of the conflict at the time when the minimum PET was observed. More specifically, this location corresponds to the center of the first vehicle where the subsequent arrival of the second vehicle to the same location was the shortest encroachment observed.

• ConflictAngle is an approximate angle of hypothetical collision between conflicting vehicles based on the estimated heading of each vehicle. The angle, expressed from the perspective of the first vehicle to arrive at the conflict point, conveys the direction from which the second vehicle is approaching the first vehicle. The angle ranges from -180 to +180 degrees, where a negative angle indicates approach from the left and a positive angle indicates approach from the right. An angle of 180 degrees (or -180 degrees) indicates a direct head-on approach, and an angle of 0 degrees (or -0 degrees) indicates a direct rear approach, as illustrated in Figure 10.

  

  Figure 10. Illustration. Conflict angle.⁽⁶⁾

• ClockAngle is an alternative expression of the conflict angle in terms of more familiar clock-hand positions. Again, the angle is expressed from the perspective of the first vehicle, with the clock time indicating the angle from which the second vehicle is approaching. The 12 o'clock position is directly ahead of the first vehicle, the 3 o'clock position is to the right, the 6 o'clock position is directly behind, and the 9 o'clock is to the left, as illustrated in Figure 11.

  

  Figure 11. Illustration. Clock angle.⁽⁶⁾

• PostCrashV is an estimate of the postcollision velocity of both vehicles. This estimate assumes that the vehicles did crash at the estimated ConflictAngle, at velocities observed at MinTTC. It also assumes an inelastic collision between the center of mass of both vehicles, where both vehicles subsequently deflect in the same direction and at the same velocity.

• PostCrashHeading is the estimated heading of both vehicles following a hypothetical collision, as discussed in PostCrashV. This heading is expressed as the angle measured counterclockwise from the x-axis (which is assumed to point right), such that 0 degrees is right, 90 degrees is up, 180 degrees is left, and 270 degrees is down. The angle ranges from 0 to 360 degrees.

• FirstVID (SecondVID) is the vehicle identification number of the first (second) vehicle. The first vehicle is the vehicle that arrives at the conflict point first. The second vehicle subsequently arrives at the same location. In rare collisions, both vehicles arrive at a location simultaneously, in which case the tie between first and second vehicle is broken arbitrarily.

• FirstLink (SecondLink) is a number indicating which link the first (second) vehicle is traveling on at tMinTTC.

• FirstLane (SecondLane) is a number indicating in which lane the first (second) vehicle is traveling on at tMinTTC.

• FirstLength (SecondLength) is the length of the first (second) vehicle in feet or meters.

• FirstWidth (SecondWidth) is the width of the first (second) vehicle in feet or meters.

• FirstHeading (SecondHeading) is the heading of the first (second) vehicle during the conflict. This heading is approximated by the change in position from the start of the conflict to the end of the conflict. Note that in most non-rear-end conflicts, at least one vehicle is turning throughout the conflict. The vehicle's actual heading would vary accordingly throughout the conflict. If the vehicle does not move during the conflict, then the direction in which it is facing is taken as the heading. This heading is expressed as the angle measured counterclockwise from the x-axis (which is assumed to point right), such that 0 degrees is right, 90 degrees is up, 180 degrees is left, and 270 degrees is down. The angle ranges from 0 to 360 degrees.

• FirstVMinTTC (SecondVMinTTC) is the velocity of the first (second) vehicle at tMinTTC.

• xFirstCSP (xSecondCSP) is the x-coordinate of the first (second) vehicle at the conflict starting point (CSP). The CSP is the location of the vehicle at tMinTTC.

• yFirstCSP (ySecondCSP) is the y-coordinate of the first (second) vehicle at the CSP. The CSP is the location of the vehicle at tMinTTC.

• xFirstCEP (xSecondCEP) is the x-coordinate of the first (second) vehicle at the conflict ending point (CEP). The CEP is the location of the vehicle at either the last time-step where the TTC value is below the specified threshold or where the last postencroachment value was observed, whichever occurs later in the conflict timeline.

• yFirstCEP (ySecondCEP) is the y-coordinate of the first (second) vehicle at the CEP. The CEP is the location of the vehicle at either the last time-step where the TTC value is below the specified threshold or where the last postencroachment value was observed, whichever occurs later in the conflict timeline.

3.3.5 Validation of the SSAM Approach

SSAM was validated in 2008 using an extensive database of 83 intersections. All were four-legged urban signalized intersections.⁽⁶⁾ Researchers conducted theoretical validation, field validation, and sensitivity analysis. The theoretical validation effort considered 11 pairs of intersection designs (e.g., right-turn bay versus no right-turn bay, SPUI versus diamond interchange, roundabout versus diamond interchange). The relative safety assessments of SSAM were compared to assessments using traditional theoretical crash-prediction equations. The results yielded interesting insights. It was often the case that design A might have more total conflicts than design B, while design B had higher severity conflicts than design A, pointing to the need for further research in interpreting and comparing surrogate measures of safety. The field validation effort was concerned with the absolute accuracy of surrogate safety assessment, in contrast to the relative safety assessments of the theoretical validation. A total of 83 intersections were used in the validation study by modeling in VISSIM^® and assessing with SSAM. The conflict analysis results of the intersections were compared to actual crash histories, based on insurance claims records, using five statistical tests. This effort also provided an opportunity for benchmark comparison of surrogate safety estimates versus traditional crash-prediction models based on average daily traffic (ADT) volumes. The simulation-based intersection conflicts data provided by SSAM were significantly correlated with the crash data collected in the field, with the exception of conflicts during path-crossing maneuvers (e.g., left turns colliding with opposing through traffic), which were underrepresented in the simulation results. Intersection rankings based on total conflict frequency were weakly correlated with intersection rankings based on total crash frequency with a Spearman rank coefficient of 0.463 and were similarly correlated for rear-end and lane-change incidents. The relationship between total conflicts and total crashes in the validation study, as shown in equation 3, exhibited a correlation (R² = 0.41).

This correlation of conflicts to crashes, albeit weak, is consistent with the range of correlations reported in several studies between ADT and crashes for urban, signalized intersections. This result was achieved despite simulating only morning peak-hour volumes. Crash prediction models based on a yearly average of 24-h ADT volumes exhibited a correlation (R² = 0.68) with actual crash frequencies. This study also found an average conflict-to-crash ratio of approximately 20,000 to 1, though that ratio varied by conflict type.⁽⁶⁾

The sensitivity analysis compared the performance of 5 intersections (taken from the aforementioned 83) implemented in each of the following microsimulation models: VISSIM^®, Aimsun, Paramics, and TEXAS. Crashes, vehicles driving through each other, were found in all simulations, and SSAM proved particularly useful in revealing questionable simulated behavior in the models. This has notably prompted some revisions (so far by TEXAS and VISSIM^®) to improve the behavior of the underlying simulation models.⁽⁶⁾