U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations
![]() |
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 ModelsPDF Version (903 KB)
PDF files can be viewed with the Acrobat® Reader® 8. Event File SpecificationGiven 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 FileThe event file will contain:
Three message types are required for each conflict event:
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] The event header at the event start time would include:
At each time step, the event details would include:
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 |