Difference between revisions of "Simulation/Output/SSM Device"

From Sumo
Jump to navigation Jump to search
m (TTC)
m (Available SSMs)
Line 126: Line 126:
 
For the calculation of those times for the approaching vehicles, we take into account the current deceleration of the  
 
For the calculation of those times for the approaching vehicles, we take into account the current deceleration of the  
 
vehicles, if the vehicle is not decelerating, the current speed is extrapolated as a constant (i.e., acceleration is only considered if it is negative).
 
vehicles, if the vehicle is not decelerating, the current speed is extrapolated as a constant (i.e., acceleration is only considered if it is negative).
 +
 +
For some reference to definitions of SSMs see for instance [Guido et al. (2011) Safety performance measures: a comparison between microsimulation and observational data] or [Mahmud et al. (2016) Application of proximal surrogate indicators for safety evaluation: A review of recent developments and research needs]
  
 
===TTC===
 
===TTC===

Revision as of 14:44, 4 October 2017

Equipping vehicles

A vehicle can be equipped with an SSM Device which logs the conflicts of the vehicle and other traffic participants (currently only vehicles) and corresponding safety surrogate measures. To attach an SSM device to a vehicle, the standard device-equipment procedures can be applied using <device name>=ssm.

For instance, a single vehicle can be equipped (with a device parametrized by default values) as in the following minimal example

<routes>
    ...
    <vehicle id="v0" route="route0" depart="0">
        <param key="has.ssm.device" value="true"/>
    </vehicle>
    ....
</routes>

The SSM device generates an output file (one for each vehicle named ssm_<vehicleID>.xml per default, but several vehicles may write to the same file). The top level elements of the generated file are

<conflict begin="<log-begin-time>" end="<log-end-time>" ego="<equipped-vehicleID>" foe="<opponent-vehicleID>"> ... </conflict>.

The detail of information given for each conflict and the criteria to qualify an encounter as a conflict (i.e., produce a corresponding conflict element in the output) can be customized by a number of generic parameters to the vehicle or device, resp.. A full parametrization (redundantly assigning the default values, here) could look as follows:

<routes>
    ...
    <vehicle id="v0" route="route0" depart="0">
        <param key="has.ssm.device" value="true"/>
        <param key="device.ssm.measures" value="TTC DRAC PET"/>
        <param key="device.ssm.thresholds" value="3.0 3.0 2.0"/> 
        <param key="device.ssm.range" value="50.0" />
        <param key="device.ssm.extratime" value="5.0" />
        <param key="device.ssm.file" value="ssm_v0.xml" />
        <param key="device.ssm.trajectories" value="false" />
        <param key="device.ssm.geo value="false" />
    </vehicle>
    ....
</routes>

Parameters

The possible parameters are summarized in the following table

Parameter Type Default Remark
measures list of strings All available SSMs This space-separated list of SSM-identifiers determines, which SSMs are calculated for the equipped vehicle's encounters (see below)
thresholds list of floats default thresholds for specified measures This space-separated list of SSM-thresholds determines, which encounters are classified as conflicts (if their measurements exceed a threshold) and thus written to the output file as a <conflict>-element. The thresholds for the available SSMs are: TTC<3.0[s], DRAC>3.0[m/s^2], PET<2.0[s]. This list is required to have the same length as the list of measures if given.
range double 50.0 [m] The devices detection range in meters. Other vehicles are tracked as soon as the are closer than <range> to the the equipped vehicle along the road-network. A tree search is performed to find all vehicles up to range upstream and downstream to the vehicle's current position. Further, for all downstream junctions in range, an upstream search for the given range is performed.
extratime double 5.0 [s] The extra time that an encounter is tracked on after not being associated to a potential conflict (either after crossing the conflict area, deviating from a common route, changing lanes, or because vehicles leave the device range, etc.).
file string "ssm_<equipped_vehicleID>.xml" The filename for storing the conflict information of the equipped vehicle. Several vehicles may write to the same file. Conflicts of a single vehicle are written in the order of the log-begin of the encounter.
trajectories bool false Whether the full time lines of the different measured values shall be written to the output. This includes logging the time values, encounter types, vehicle positions and velocities, values of the selected SSMs, and associated conflict point locations. If turned off (default) only the extremal values for the selected SSMs are written.
geo bool false Whether the positions in the output file shall be given in the original coordinate reference system of the network (if available).

Encounter types

Different types of encounters, e.g. crossing, merging, or lead/follow situations, may imply different calculation procedures for the safety measures. Therefore the SSM-device keeps track of these classifications and provides them in the output to allow the correct interpretation of the corresponding values.

The following table lists the different encounter types along with their codes, which will appear in the output file.

Caution:
This is still under development and may be subject to change!
Code Name Description
0 NOCONFLICT_AHEAD Foe vehicle is closer than range, but not on a lane conflicting with the ego's route ahead.
1 FOLLOWING General follow/lead situation (incomplete type, used only internally).
2 FOLLOWING_FOLLOWER Ego vehicle is following the foe vehicle.
3 FOLLOWING_LEADER Foe vehicle is following the ego vehicle.
4 ON_ADJACENT_LANES Foe vehicle is on a neighboring lane of the ego vehicle's lane, driving in the same direction.
5 MERGING Ego and foe share an upcoming edge of their routes while the merging point for the routes is still ahead (incomplete type, only used internally).
6 MERGING_LEADER As 5. The estimated arrival at the merge point is earlier for the foe than for the ego vehicle.
7 MERGING_FOLLOWER As 5. The estimated arrival at the merge point is earlier for the ego than for the foe vehicle.
8 MERGING_ADJACENT As 5. The Vehicles' current routes lead to adjacent lanes on the same edge.
9 CROSSING Ego's and foe's routes have crossing edges (incomplete type, only used internally)
10 CROSSING_LEADER As 6. The estimated arrival of the ego at the conflict point is earlier than for the foe vehicle.
11 CROSSING_FOLLOWER As 6. The estimated arrival of the foe at the conflict point is earlier than for the ego vehicle.
12 EGO_ENTERED_CONFLICT_AREA The encounter is a possible crossing conflict, and the ego vehicle has entered the conflict area. (Is currently not logged -> TODO)
13 FOE_ENTERED_CONFLICT_AREA The encounter is a possible crossing conflict, and the foe vehicle has entered the conflict area. (Is currently not logged -> TODO)
14 EGO_LEFT_CONFLICT_AREA The encounter has been a possible crossing conflict, but the ego vehicle has left the conflict area.
15 FOE_LEFT_CONFLICT_AREA The encounter has been a possible crossing conflict, but the foe vehicle has left the conflict area.
16 BOTH_ENTERED_CONFLICT_AREA The encounter has been a possible crossing conflict, and both vehicles have entered the conflict area (auxiliary type, only used internally, is evaluated to BOTH_LEFT_CONFLICT_AREA or to COLLISION).
17 BOTH_LEFT_CONFLICT_AREA The encounter has been a possible crossing conflict, but both vehicle have left the conflict area.
18 FOLLOWING_PASSED The encounter has been a following situation, but is not active any more.
19 MERGING_PASSED The encounter has been a merging situation, but is not active any more.
111 COLLISION Collision (currently not implemented, might be differentiated further).

Available SSMs

Currently, the following safety surrogate measures are implemented:

  • TTC (time to collision)
  • DRAC (deceleration rate to avoid a crash)
  • PET (post encroachment time)

For the selection in the device's output, the abbreviations have to be used.

Basically, we distinguish between three types of encounters for two vehicles:

  • Lead/follow situation
  • Crossing situation
  • Merging Situation

Please note that some SSMs only apply to a specific encounter or are computed differently for different encounters. For crossing and merging situations, we consider "expected" entry and exit times with respect to the conflict zone. For the calculation of those times for the approaching vehicles, we take into account the current deceleration of the vehicles, if the vehicle is not decelerating, the current speed is extrapolated as a constant (i.e., acceleration is only considered if it is negative).

For some reference to definitions of SSMs see for instance [Guido et al. (2011) Safety performance measures: a comparison between microsimulation and observational data] or [Mahmud et al. (2016) Application of proximal surrogate indicators for safety evaluation: A review of recent developments and research needs]

TTC

The time-to-collision is defined for all follow-lead situations for which the follower is faster than the leader. It is given as

   TTC = space_gap/speed-difference.

For a crossing or merging situation the TTC is only considered defined if for the case that the expected conflict area exit time of the vehicle A is larger than the expected conflict area entry time for vehicle B, where A is the vehicle with the smaller expected conflict area entry time. If this is the case the TTC is defined as

  TTC = B's distance to conflict area entry / B's current speed.

DRAC

For a lead/follow-situation the DRAC (deceleration to avoid a crash) is defined as

   0.5*speed_difference^2/space_gap

PET

Conflict area is simplified, merging area is not treated, DRAC for merging is still incomplete

Output

TODO: provide example output + table with element specification