Overview#
The ToC Device provides facilities to model a take-over of control (ToC) in automated vehicles. It was developed within the project TransAID, see Lücken et al.(2019) [1].
To this end the user has to specify at least the two vehicle types, which should be used as models of automated and manual driving. All supported parameters are described below.
The transition of control can take place in two directions:
- driver->automation ("upward transition")
- automation->driver ("downward transition")
Presumably, the more complex process is the downward transition, where the human driver is supposed to take back control from the vehicle automation, as the driver's condition right after the take-over event may allow only a reduced driving performance. The ToC Device divides the downward transition into two states:
- The 'preparing' state, where a take-over request (TOR) has been issued, but the driver has not taken back the control of the vehicle.
- The 'recovering' state, just after the ToC, where the driver shows decreased driving performance (see below for details).
Further, the device induces a minimum risk maneuver (MRM) if the driver does not take back the vehicle control within a specified lead time (see figure).
Figure 1: Timeline of a ToC as modelled by the ToC Device
Configuration#
To equip vehicles with the ToC functionality, the generic equipment
functionality of devices can be employed, see the description of
equipment
procedures
(and use <device name>=toc). The minimal definition required to equip
one vehicle with a ToC Device has the following form:
<routes>
...
<vehicle id="v0" route="route0" depart="0">
<param key="has.toc.device" value="true"/>
<param key="device.toc.automatedType" value=<AUTOMATED_VTYPE_ID> />
<param key="device.toc.manualType" value=<MANUAL_VTYPE_ID> />
</vehicle>
....
</routes>
The following table gives the full list of possible parameters for the
ToC Device. Each of these parameters must be specified as a child
element of the form <param key=<PARAMETER NAME> value=<PARAMETER VALUE> of the appropriate demand definition element
(e.g. <vehicle ... />, <vType ... />, or <flow ... />).
| Parameter | Type | Default | Description |
|---|---|---|---|
| manualType | vTypeID (string) | none (mandatory) | ID of the vehicle type used to model manual driving. |
| automatedType | vTypeID (string) | none (mandatory) | ID of the vehicle type used to model automated driving. |
| responseTime | float | 5.0 | The time (in [s]) it takes the driver after the TOR (see TORs below) to take back the control over the vehicle. |
| initialAwareness | float | 0.5 | The awareness assigned to the driver after a the ToC. The value must lie within [0.0, 1.0], where 1.0 corresponds to normal driving performance and lower values lead to increased perception errors (see below). |
| lcAbstinence | float | 0.0 | The awareness level below which no lanechanges are performed by the driver. The value must lie within [0.0, 1.0]. Per default this is disabled, setting its value to 1.0 prevents deliberate lane changes for the whole recovery phase. |
| recoveryRate | float | 0.1 | The rate (in [1/s]) at which the driver's performance recovers after the ToC. |
| mrmDecel | float | 1.5 | The braking rate (in [m/s²]) at which the vehicle brakes if the driver does not take back control within a specified time (see TORs below). |
| dynamicToCThreshold | float | 0.0 | Time, which the vehicle requires to have ahead to continue in automated mode. The default value of 0.0 indicates no dynamic triggering of ToCs. |
| dynamicMRMProbability | float | 0.05 | Probability that a dynamically triggered TOR is not answered in time. |
| mrmKeepRight | bool | false | If true, the vehicle tries to change to the right during an MRM. |
| mrmSafeSpot | string | "" | If set, the vehicle tries to reach the given named stopping place during an MRM. |
| mrmSafeSpotDuration | float | 60.0 | Duration the vehicle stays at the safe spot after an MRM. |
| maxPreparationAccel | float | 0.0 | Maximal acceleration that may be applied during the ToC preparation phase. |
| ogNewSpaceHeadway | float | 0.0 | The target additional space headway during the preparatory phase before a ToC (see openGap()). |
| ogNewTimeHeadway | float | original value | The target time headway during the preparatory phase before a ToC (see openGap()). |
| ogChangeRate | float | 1.0 | The change rate of headway adaption during the preparatory phase before a ToC (see openGap()). |
| ogMaxDecel | float | 1.0 | The maximal deceleration rate due to headway adaption during the preparatory phase before a ToC (see openGap()). |
| useColorScheme | bool | True | Whether the equipped vehicles shall be colored according to their current ToC State. The colors for the transitional states (preparing ToC, recovering from ToC, and executing MRM) are hard-coded, currently. |
| file | string | "" | Specifying a filename here switches on the output for the device, which reports events of the take over process (ToCup, ToCdown, TOR, MRM). |
If none of the og... elements is given, no headway adaptation will be
performed during the ToC preparation phase.
Take-over requests#
To induce a switch between the manual and automated vehicle types, the user has to issue a take-over request (TOR) via TraCI. The corresponding command is (here exemplary for the python client)
traci.vehicle.setParameter(<VEHICLE_ID>, "device.toc.requestToC", <AVAILABLE_LEAD_TIME>)
If the current driving mode is automated, this will induce a switch to
the manual vehicle type after the specified (or default) responseTime,
or, if responseTime > availableLeadTime, an MRM is initiated (and
interrupted after responseTime). During the MRM, the vehicle brakes at
the specified (or default) constant rate mrmDecel. After
responseTime has elapsed, the vehicle type is switched and the
awareness parameter of the vehicle's driver
state is set to the initialAwareness.
Hereafter, the awareness grows linearly with rate recoveryRate until it
reaches its maximum value (=1.0) after
(1.0-initialAwareness)/recoveryRate seconds.
If the current driving mode is manual, a TOR will induce an immediate
switch to the automated vehicle type and any given value for the
availableLeadTime is ignored (a warning will be issued if positive
values are given).
Dynamic TORs#
A TOR can be issued without external command if the parameter
dynamicToCThreshold is supplied with a positive value. It induces a
TOR if the vehicle cannot continue on its current route for longer than
the given value (in seconds) due to impeded lane changes. The
corresponding TOR is currently issued with a lead time of 3/4 of the
given dynamic-ToC threshold.
Reduced Driving Performance#
During the recovering phase following a ToC, the driver of the automated vehicle is assumed to drive with a decreased performance. This is modeled by temporarily elevated magnitudes of the driver's perception errors, i.e., a decreased driver awareness (see Driver State).
References#
- Lücken, L., Mintsis, E., Kallirroi, N. P., Alms, R., Flötteröd, Y. P., & Koutras, D. (2019). From Automated to Manual - Modeling Control Transitions with SUMO. EasyChair. SUMO User Conference 2019, 13.-15. May 2019, Berlin, Germany. https://doi.org/10.29007/sfgk