ToC Device

Overview

The ToC Device provides facilities to model a take-over of control (ToC) in automated vehicles.

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's is supposed to take back control from the vehicle automation, as the drivers 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 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 ... />)

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 maximal 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).

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).