U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations

Report
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-HRT-08-051
Date: June 2008

Surrogate Safety Assessment Model and Validation: Final Report

PDF Version (3.39 MB)

PDF files can be viewed with the Acrobat® Reader®

Chapter 2. SSAM Software

This chapter provides a brief overview of the SSAM software, developed to automate the process of identifying conflicts and calculating surrogate safety measures. [3] The software overview is organized into the following sections:

  • SSAM workflow.
  • Conflict identification algorithms.
  • Terms and definitions.

The SSAM software and corresponding user manual are available upon request from the Federal Highway Administration (FHWA). [4]

SSAM Workflow

This section provides an overview of the typical workflow of using the SSAM software, tracing the flow of information through various input data, tasks or operations, and resulting outputs. In doing so, many of the screens of SSAMs graphic user interface (GUI) 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 (where files are labeled with 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 safety measures is then presented to the user. Figure 1 illustrates the workflow for using SSAM.

Figure 1. Illustration. SSAM Operational Concept. This screen shows the operational concept of SSAM. First, the traffic simulation software generates the SSAM input data-the vehicle trajectory file. Then, SSAM loads the files to process them. The results are presented to the user.

Figure 1. Illustration. SSAM Operational Concept.

The traffic engineer begins the analysis by first enabling output of vehicle interaction (or 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 traffic engineer then launches the stand-alone SSAM application. The user interface of SSAM is shown in figure 2.

Figure 2. Screen Capture. SSAM User Interface after Launching. This is when SSAM is launched the first time after installation.

Figure 2. Screen Capture. SSAM User Interface after Launching.

The user begins by defining a new conflict analysis case by using the Menus to create a new case file (or alternatively to open an existing case file). The user interface provides a tree-view listing of all existing case documents in the left-hand pane of the display, as shown in figure 3 (with a single existing case document). One or more case documents may be viewed in the workspace in the right-hand pane. Figure 3 shows a case document where various views of its corresponding input and output data are organized in a multi-tabbed format. In particular, the Configuration tab (or panel), shown in figure 3, allows the user to browse the file system and select one or more trajectory files to be processed for the current case. 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 value of

  • Time-to-collision (TTC).
  • Post-encroachment time (PET).

The software provides default threshold values for these measures, which the analyst may optionally override with his or her preferred alternate values. SSAM utilizes a default TTC value of 1.5 seconds, as suggested in previous research.(10, 11) Use of a PET threshold is attributed to research by Hyden.(12)

Once the conflict identification thresholds are determined, the user presses the Analyze button, and simulation (trajectory) data are processed to identify vehicle-to-vehicle interactions which 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 in a table (the conflict table) under the Conflicts tab, which is shown in the right-hand pane in figure 4. The conflict table shows all conflict details, including the time, location, and all surrogate measures of safety for that conflict.

Figure 3. Screen Capture. SSAM User Interface with Case File Defined. This is a screen capture of the SSAM user interface for the defined case file. An example case file named "Sam1" appears in a tree view in the left-hand pane of the display. The detailed configuration of this case file is shown in the right-hand pane of the display.

Figure 3. Screen Capture. SSAM User Interface with Case File Defined.

Figure 4. Screen Capture. SSAM User Interface with Conflicts Tab Selected. This is a screen capture of the SSAM user interface for the conflict tab of the example case file. Each conflict identified in the case is listed in the conflict table, which is shown in the right-hand pane of the display. The conflict table shows all conflict details, including the time, location, and all surrogate measures of safety for that conflict.

Figure 4. Screen Capture. SSAM User Interface with Conflicts Tab Selected.

SSAM also provides a Summary screen for each case, as shown in figure 5. Users click the summary tab to switch from the conflict table to a view of summary statistics. Summary statistics include the number of different conflict types for each simulation replication, as well as the average and total values over all replications. Additionally, average values of each proposed surrogate measure are presented in the summary.

Figure 5. Screen Capture. SSAM User Interface with Summary Tab Selected. This is a screen capture of the SSAM user interface for the summary tab of the example case file. Summary statistics include the number of different conflict types for each simulation replication and the average and total values over all replications. Additionally, average values of each proposed surrogate measure are presented in the summary.

Figure 5. Screen Capture. SSAM User Interface with Summary Tab Selected.

SSAM also includes a Filter tool, shown in figure 6, which can be accessed via the Filter tab of the case display. By configuring filter parameters, the user can effectively instruct the software, Show me all rear-end conflict events where the speed differential was greater than 40.25 km/h (25 mi/h) occurring in lane 5 of link 12. Once the filter is applied, only those conflicts satisfying the filter criteria appear in the conflict table, and the summary statistics are recomputed for this subset of the conflicts.

SSAM also supports analysis and report generation by providing copy and paste features so that data from the filtered conflict table may be transferred to a spreadsheet application such as Microsoft Excel®. Alternatively, the table can be exported (i.e., saved to a file) in comma separated values (CSV) format, which is a universal format that can be imported into other applications for statistical analysis, charting, and report generation. Figure 7 shows an exported CSV file as it appears when opened with the Microsoft Excel spreadsheet application.

Figure 6. Screen Capture. SSAM User Interface with Filter Tab Selected. This is a screen capture of the SSAM user interface for the filter tab of the example case file. By configuring the filter parameters, only those conflicts satisfying the filter criteria will display in the conflict table once the filter is applied, and the summary statistics will recompute for this subset of the conflicts.

Figure 6. Screen Capture. SSAM User Interface with Filter Tab Selected.

Figure 7. Screen Capture. CSV File from SSAM. This is a screen capture of a Microsoft Excel® file named as "export.csv". This file is exported from SSAM and contains detailed information for all conflicts.

Figure 7. Screen Capture. CSV File from SSAM.

In addition, the SSAM software also features two additional screens which also appear as tabs on the user-interface. These additional screens are a Map panel and a t-test panel. The Map panel allows a user to display a map or image of the underlying roadway network and overlay conflicts on that map. The map display can be exported to an image file to facilitate report generation. In additional, the t-test panel can be used to calculate statistical property of the conflict data to facilitate comparisons.

More information about SSAM is available in a corresponding user manual.

CONFLICT IDENTIFICATION ALGORITHMS

This section summarizes the algorithms used by SSAM to identify conflicts from the vehicle trajectory files (TRJ files) to be processed. This can be a computationally intensive task 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 minutes to process data from 5 hours of traffic for a single intersection model. Large multi-intersection networks might require hours of processing time. The following steps summarize the technique 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 8. Individual square zones cover 15.25-m by 15.25-m (50-ft by 50-ft) areas depending on the units specified in the TRJ file. By dividing the region into these zones, the number of vehicle-to-vehicle comparisons necessary to identify potential conflicts is reduced considerably.

Figure 8. Illustration. Illustration of Zone Grid. This screen illustrates the concept of zone grid. SSAM reads in the header of the TRJ file, which defines the dimensions of the analysis area. These dimension data are used to set up a zone grid in SSAM, which is the region containing all observable vehicles' positions within the TRJ file. The whole region is then divided into many small square zones, each having a zone side of 15 m (50 ft).

Figure 8. Illustration. Illustration of Zone Grid.

Step 2

Analyze a single time step of a trajectory file. For each vehicle in the analysis region, SSAM projects that vehicles expected location as a function of its current speed, if it were to continue traveling along its (future) path for up to the duration of the configured time-to-collision (TTC) value. A vehicles projected path is based on a look ahead over the next 10 seconds of trajectory data. The path, as shown in figure 9, is a set of straight line segments (labeled S) connecting the vehicles 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 seconds. Conflicts with TTC values larger than 1.5 seconds are not generally considered in the safety community to be severe enough events for recording in a traditional field conflict study.

Figure 9. Illustration. Illustration of Vehicle Path. This screen illustrates how to define a vehicle path in SSAM. Each vehicle in the zone grid during a single time step of trajectory file is projected forward along its path over the duration of the threshold TTC value (e.g., S1, S2, etc.). The vehicle's path is the set of line segments composed of the vehicle's sequential locations in the future.

Figure 9. Illustration. Illustration of 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 occurs as follows, assuming SSAM is going to analyze the conflicts for vehicle A at time t1. First, SSAM extracts all data related with vehicle A from the trajectory file, such as vehicle As location, speed, acceleration, etc., at time t1 and several time steps after t1. Each location is denoted as (x1,y1), (x2,y2), etc. Then SSAM projects vehicle As distance forward along its trajectory defined by those locations:

  1. Each vehicle is defined as a polygon (rectangle) with four corner points (shown in figure 10).
  2. The forward distance that the vehicle will travel is calculated in the MaxTTC interval, denoted as DIS1= V1 * MaxTTC (shown in figure 10).
  3. The vehicles next time step location (x2,y2) is calculated based on the distance from current location to that location, denoted as DIS2=|Location (t+1)-Location (t)| (shown in figure 10).
  4. If DIS2 is less than DIS1, then DIS2 is subtracted from DIS1 and the previous two calculations are repeated, updating DIS1=DIS1-DIS2 and DIS2=|Location (t+2)-Location (t+1)| and comparing the new DIS1 and DIS2 (shown in figure 11).

Figure 10. Illustration. DIS1 and DIS2. This screen illustrates how to calculate the distance that the vehicle will travel in the maxTTC interval and the distance from current location to next-time-step location.

Figure 10. Illustration. DIS 1 and DIS 2.

Figure 11. Illustration. Updated DIS1 and DIS2 when Old DIS1 > DIS2. This screen illustrates how to update DIS1 and DIS2 when old DIS1 is greater than DIS2. If DIS2 is less than DIS1, then subtract DIS2 from DIS1 and update DIS1 as DIS1 minus DIS2 and DIS2 as the distance from the current location to the next time step location.

Figure 11. Illustration. Updated DIS 1 and DIS 2 when Old DIS 1 > DIS 2.

  1. If DIS2 is more than DIS1, then the x-y position is calculated to locate the projection point within the segment of DIS2 (shown in figure 12).

Figure 12. Illustration. Projection Point when DIS1 < DIS2. This screen illustrates how to update DIS1 and DIS2 when old DIS1 is smaller than DIS2. If DIS2 is more than DIS1, then calculate the x-y position of the vehicle where the projection point within the segment of DIS2 in the distance of DIS1 will be located.

Figure 12. Illustration. Projection Point when DIS 1 < DIS 2.

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 the vehicle to that zone, or rather, 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 13. SSAM maintains a list of all conflicting vehicle-pairs (all conflict events) for the current time-step. 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 is added to the conflict list for the current time-step (if not already in the list).

Figure 13. Illustration. Checking Conflict Between Two Vehicles at MaxTTC. This screen illustrates how to check conflict between two vehicles at Max TTC within the zone grid. Place all vehicles' projections on the zone grid and calculate which zones the vehicles are fully or partially within. Any time two vehicles are in the same zone, check for overlap of the vehicle rectangles, which indicates that a conflict has been identified. This check is done by testing all sides of one vehicle for intersection with all sides of the other vehicle over the entire 0-maxTTC range of projection times.

Figure 13. Illustration. Checking 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 as follows:

  1. 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 as before over successively short 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 14, where the TTC values have reduced from the maxTTC value of 1.5 seconds (illustrated previously in figure 13) to a TTC value of 1.3 seconds. Instead of the large overlap in figure 13, the vehicles in figure 14 have just barely come into contact. Note that if the projection timeline reduces to 0 seconds and the vehicles still overlap, then this is a crash.
  2. At this point, various surrogate safety measures, such as the minTTC (taking the minimum of the current TTC value and that of the prior time-step, if applicable), are calculated and updated. Also, the current (actual) positions of both vehicles are recorded for post-encroachment analysis.
  3. If it was found that the vehicle-pair does not overlap over any projection time between 0 and maxTTC, then this vehicle-pair has made its way into 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 one vehicle (the trailing vehicle) to eventually occupy (or encroach on) on a position formerly held by the other vehicle (the leading vehicle). The time differential between when the leading vehicle occupied this location and the trailing vehicle arrived is the post-encroachment time (PET). If a post-encroachment was observed, then the minimum PET is updated, and this conflict event remains in the list, as the post-encroachment could potentially reduce as the vehicle trajectories progress over time.
  4. 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 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 end points, conflict angles, and DeltaV. Also, the conflict is classified at this time as a crossing conflict, rear-end conflict, or lane-change conflict. The next section defines all surrogate measures and provides the conflict type classification logic. 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.

Figure 14. Illustration. Checking Conflict Between Two Vehicles at TTC=1.3 (Vehicles No Longer in Conflict). This screen further illustrates how to check conflicts between two vehicles at a TTC equal to 1.3, a value less than maxTTC of 1.5. Reproject the vehicles' positions over smaller increments (denoted as TTC) ranging from maxTTC to 0 (in this case 1.3) and check for overlapping of the two vehicles. In this case, the two vehicles are no longer in conflict when TTC is at 1.3.

Figure 14. Illustration. Checking Conflict Between Two Vehicles at TTC = 1.3 (Vehicles No Longer in Conflict).

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. This 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.

tMinTTC is the simulation time when the minimum TTC (time-to-collision) 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 the each vehicle (see explanation of FirstHeading). The angle, expressed in 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°, where a negative angle indicates approach from the left and a positive angle indicates approach from the right. An angle of 180° (or -180°) indicates a direct head-on approach, and an angle of 0° (or -0°) indicates a direct rear approach, as illustrated in figure 15.

Figure 15. Illustration. Conflict Angle. This screen illustrates the conflict angle in SSAM. It is an approximate angle of hypothetical collision between conflicting vehicles based on the estimated heading of the each vehicle. The angle, expressed in 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 negative180 degrees to positive180 degrees, where a negative angle indicates the approach from the left and a positive angle indicates approach from the right. An angle of 180 degrees (or negative 180 degrees) indicates a head-on approach, and an angle of 0 degrees (or negative 0 degrees) indicates a rear approach. In this case, the conflict angle is 45 degrees.

Figure 15. 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 in the perspective of the first vehicle, with the clock time indicating the angle from which the second vehicle is approaching. The 12:00 position is directly ahead of the first vehicle, 3:00 is to the right, 6:00 is directly behind, and 9:00 is to the left, as illustrated in figure 16.

Figure 16. Illustration. Clock Angle. This screen illustrates the clock angle in SSAM. It is an alternative expression of the conflict angle in terms of more familiar clock hand positions. The angle is expressed in the perspective of the first vehicle, with the clock time indicating the angle from which the second vehicle is approaching. The 12:00 position is directly ahead of the first vehicle, 3:00 is to the right, 6:00 is directly behind, and 9:00 is to the left. In this case, the clock angle is 4:30.

Figure 16. Illustration. Clock Angle.

PostCrashV is an estimate of the post collision velocity of both vehicles. This estimate assumes that the vehicles did crash at the estimated ConflictAngle, at velocities observed at the tMinTTC. 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° is right, 90° is up, 180° is left, and 270° is down. The angle ranges from 0° to 360°.

FirstVID (SecondVID) is the vehicle identification number of the first (second) vehicle. The first vehicle is the vehicle that arrives to the conflict point first. The second vehicle subsequently arrives to the same location. In rare cases (actually collisions), both vehicles arrive to a location simultaneously, in which case the tie between first and second vehicle in 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. Its actually 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° is right, 90° is up, 180° is left, and 270° is down. The angle ranges from 0° to 360°.

FirstVMinTTC (SecondVMinTTC) is the velocity (speed) 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 post-encroachment 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 post-encroachment value was observed, whichever occurs later in the conflict timeline.

Definitions of Surrogate Measures Computed by SSAM

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 post-encroachment time observed during the conflict. Post-encroachment time is the time between when the first vehicle last occupied a position and the time when the second vehicle subsequently arrived to the same position. A value of zero indicates a collision. A post-encroachment time 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 time-to-collision 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 brake, 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 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 as follows. The type is classified as a rear-end conflict if ||ConflictAngle|| < 30°, a crossing conflict if ||ConflictAngle|| > 85°, or otherwise a lane-changing conflict. However, the simulation model that produced the vehicle trajectory data can generally provide link and lane information for both vehiclesthough the coding of these values may vary significantly from one simulation vendor to the next. 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 (while having not changed links), then the event is classified as a lane-change. 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 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 (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 consider changing links, depending on the underlying simulation model. In some cases, vehicles which appear to be traveling in the same lane may actually by considered by the simulation model as traveling on different links that happen to overlap.

MaxDeltaV is the maximum DeltaV value of either vehicle in the conflict (see FirstDeltaV or SecondDeltaV for more information).

FirstDeltaV (SecondDeltaV) is the change between conflict velocity (given by speed FirstVMinTTC and heading FirstHeading) and the postcollision 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.

Previous | Table of Contents | Next

Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000
Turner-Fairbank Highway Research Center | 6300 Georgetown Pike | McLean, VA | 22101