• Federal Highway Administration >
• Publications >
• Research Publications >
• 03050 >
• 08.Cfm >
• Surrogate Safety Measures From Traffic Simulation Models

Surrogate Safety Measures From Traffic Simulation Models

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:

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.

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]

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