Skip to contentUnited States Department of Transportation - Federal Highway Administration FHWA Home
Research Home
Report
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-RD-03-050

Surrogate Safety Measures From Traffic Simulation Models

PDF Version (903 KB)

PDF files can be viewed with the Acrobat® Reader®

8. Event File Specification

Given the calculation algorithms specified above, the next step is to specify the format of the output file and determine how the calculations can be split up between the simulation model and the surrogate safety module. To make it as easy as possible for simulation model developers to support the event file format with a minimum of additions/changes to existing software, there will be more information in the event file list than only valid conflict events (this would indicate that the entire surrogate measures calculation algorithms were embedded in the simulation model). The surrogate safety module would then post-process the event file to extract valid conflict events and compute surrogate measures.

Elements in the Event File

The event file will contain:

  • All lane-change events.
  • All gap-acceptance events—crossing flows.
  • All gap-acceptance events—entering flows.
  • All events where a vehicle makes a turn with a vehicle following that causes braking.
  • All events where a leader vehicle brakes and causes the following vehicle to brake.

Three message types are required for each conflict event:

  • Event start.
  • Event continue.
  • Event end.

The "event continue" entry is needed because the surrogate measures calculations require a time history of state variables for both the leader and follower vehicles (i.e., to find minimum TTC and PET and maximum DeltaS and MaxS). A sequential text file of the resulting format could look like this:

Time 1

[event ID(1) – start]

[event details header – start]

[event details]

[event ID(2) – start]

[event details header – start]

[event details]

Time 2

[event ID(1) – continue]

[event details]

[event ID(2) – continue]

[event details]

[event ID(3) – start]

[event details header – start]

[event details]

Time 3

.

.

.

Time n

[event ID(1) – end]

[event details]

[event ID(2) – continue]

[event details]

[event ID(3) – continue]

[event details]

.

.

.

[event ID(k-1) – continue]

[event details]

[event ID(k) – end]

[event details]

[event ID(k+1) – start]

[event details header – start]

[event details]

Elements in the Header

The event header at the event start time would include:

  1. Event ID number.
  2. Intersection ID and control type.[10]
  3. Event type (conflict point, line, rear-end line) and subtype identifier (e.g., encroaching vehicle left turn to side street in front of right-of-way vehicle).
  4. Vehicle ID numbers.
  5. Lane number of the leader and follower vehicles.
  6. Approach number of the leader and follower vehicles.
  7. Intended movement of the leader and follower vehicles.
  8. Vehicle mass and performance variables for leader and follower vehicles.
  9. Vehicle driver behavior variables.
Elements in Each Time Step

At each time step, the event details would include:

  1. Event ID number.
  2. If signalized, current signal phase states.
  3. Latitude and longitude of leader and follower vehicles.
  4. Velocity of leader and follower vehicles.
  5. DR of leader and follower vehicles.
  6. Turning signal state of leader vehicle (if available).
  7. Time-varying driver behavior parameters.[11]
Implications of File Size

The event file may become very large in size due to the limited amount of filtering provided by the simulation model developers. With more filtering according to the computational algorithms of the previous section, the file would be much smaller. If more filtering could be done by the simulation model itself, then the event file format might also change. For example, consider filtering the candidate conflict events based on deceleration events by the following or right-of-way vehicle. This would require a different file format since the event details would only be output by the simulation model after the deceleration event was identified. With the current specification, this could not be done.

File Naming Conventions

One event file would be produced for each simulation iteration with a naming convention so that the surrogate measures software could import each file automatically when the user enters the root file name and the increment format and is pointed to the correct directory where the files reside.[12] For example, "testcase001, testcase002,…, testcase045" would have a root of testcase and an increment of NNN.


 

[10] Assumes the simulation includes multiple intersections. If only one intersection is modeled, the data element is not required. back

[11] If any (e.g., increased aggressiveness due to queue wait time is modeled in some simulations). back

[12] It would be advisable, as indicated in the functional requirements section, that this event file be based on a standard inter-simulation exchange format (e.g., XML based on the TMML). back

Previous | Table of Contents | Next

ResearchFHWA
FHWA
United States Department of Transportation - Federal Highway Administration