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.
The 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:
Elements in the HeaderTime 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
Previous | Table of Contents | Next
|
TFHRC
Home | FHWA Home | Feedback
United States Department of Transportation - Federal Highway Administration |