Table of Contents:

Design Constraints and Guidelines for the Automation- Human Interface

DESIGN CONSTRAINTS

The design constraints were developed by the HLDAVe team to guide our studies and design of the automation-human interfaces. As such, they represent some of our early thinking on the project. Thirty-one, high-level, design constraints were identified as follows.

Allow Driver to Take Control at Any Point during Takeover, Be Sure Hands on Wheel and Feet on Pedals

System needs to prompt driver to have hands on wheel and feet on pedals prior to takeover. Pedals and wheel need to move in response to vehicle inputs, such as braking and accelerating. If driver inputs are detected, then automation should drop out.

Personalise Takeover Based on Driver Preferences (And Situation)

Takeover customisation menu allowing driver to personalise the takeover protocol - above the minimum requirements (for both short and long takeover protocols).

Allow Option to Complete Non-driving Task (Even If It Means Missed Takeover for Junction/Exit)

If no inputs are detected from the driver by the automation in response to the takeover protocol (after detecting that driver is awake and active in the vehicle), then carry on to next junction (may have to exit and turn back if the next junction does not fit in with planned route).

Allow Sufficient Time for Takeover (Big Individual Differences in Our Studies)

Default takeover needs to occur with sufficient time to exit junction (such as 5 min before junction - this is an arbitrary figure). Allow the driver to customise this time in the takeover set-up menu.

Customise Takeover Based on Duration of Being Outside of the Control Loop and Frequency of Takeover (And Context: Road, Weather, Other Road Users, Infrastructure, Signage) - Multimodal Human-Machine Interface (HMI)

See design constraint number 2. This may be too complex to undertake. Remember KISS design principle: Keep It Simple Stupid!

Querying Situation Awareness of Driver by 'Vehicle Avatar'

The chatty co-driver concept: natural language interaction with vehicle automation on aspects related to the driving task.

Make Explicit Who Is in Control of Vehicle - Mode Awareness HMI (Light-up Steering Wheel)

Need colour coding for light-up wheel to show who is driving. Not light would mean driver is in control. Could be traffic light colours. Red=driver must take control; Amber=driver prepare to take control; Green = automation is in control; Blue = automation can take control if driver releases wheel. Trouble with colour coding is colour blindness. This coding needs to be supplemented with information about mode of control on the head-up display (HUD).

Recommended Settings Based on Customer Profiles for Customisation

Need to take customer preferences and profiles into account. For example, the driver may be deaf.

Pre-set Defaults for Takeover

See design constraint number 4.

Graduated Alert to Takeover Visual, Audio, Haptic (Escalating)

Takeover prompt begins with visual information. If this is not responded to within 1 min (arbitrary figure), it is backed up with auditory information. If the auditory information is not responded to with 30 s (arbitrary figure), it is backed up with haptic information. If the haptic information is not responded to within 15 s (arbitrary figure), the driver is informed that the car will progress to the next junction (via visual and auditory information). If there are no more junctions, then the vehicle needs to pull over on the hard shoulder and make a safe stop.

Cue Driver to 'Grab' Steering Wheel

Light up steering wheel to indicate that driver needs to take control.

Make 'Takeover Button' Easy to Access (e.g. Put on Gear Stick)

Not sure we need a ‘takeover’ button, as the driver just needs to grab the steering wheel and/or place feet on pedals. Suggest that if the driver only grabs the steering wheel, then longitudinal control is still automated (like adaptive cruise control).

'Repeat' Button and 'OK' Button?

Place ‘repeat’ button on steering wheel, so that the last verbal information or instruction can be repeated back to the driver. Also, place an ‘OK’ button on steering wheel so that driver can acknowledge system without having to give verbal acknowledgement (if they do not wish to).

Encourage (Facilitate) Visual Checks in Environment and Controls of Vehicle

Where possible, show information on the HUD, such as the identification of other vehicles, hazards, road signage, path of vehicle, vehicle status, and vehicle intentions.

Display the Vehicle Status and Intention

Use HUD on windscreen to display status of the vehicle (such as the current mode of the vehicle and the status of vehicle sensors) as well as the intended path of the vehicle (arrow on road) and also inform driver of any planned manoeuvre (such as a lane change, braking, and accelerating).

Driver's HMI Actions Need to Be Clearly Fed Back

(Link to 1 - Volvo Hands on Wheel to Flip Both Paddles)

See design constraint number 7.

Eyes Out

Place information on HUD where possible. Use the windscreen as the interface between the driver and the automation.

Use System to Aid Manual Driving

Option to have HUD switched on even when driving manually, to show path of vehicle and pick out relevant information in road environment (such as the detection of other vehicles and road signage).

Some Level of Personalisation and Setting of Levels

Basic minimum takeover protocol includes instruction to grab vehicle controls and motorway exit distance (if appropriate). Additional information is available that can be supplied if desired, which can be added in a personalisation takeover menu.

Longer Automated Vehicle-to-Human Driver Takeover in Urban Environment (Compared to Motorway)

This could be set up in the defaults and personalisation menu. We are focusing on motorway takeover in our use-case, so wonder if we should tackle urban yet as it seems to be too complex.

Takeover Strategy That Guides Visual Search

Use HUD to pick out information of relevance to takeover, such as position of other vehicles that pose potential hazards, signage for exit (if relevant), path of vehicle, lane position, and so on.

Feedback to Every Driver Action (Process Needs Adapting to Driver and Situation)

This has already been addressed in other design constraints.

Checklist

This constraint conveys the need to have a systematic takeover process, from vehicle by driver as well as handover from driver to vehicle.

Option to Request Specific Information of Importance to Driver (If Not in Protocol)

Design a question and answer protocol with an ‘Alexa-like’ interaction.

Education of Drivers in Rationale and Technique

Education of the driver in the takeover and limitations of vehicle automation could be provided in the manual, on-line training (You Tube?) and within the vehicle via head-down display and HUD (when the vehicle is stationary).

Training (Video) before Being Able to Use Autopilot on Roads

Training - similar media to design constraint number 25.

Older Drivers Do Not Like to Constantly Monitor Automation for Takeover (Timer Only) Trend Only

Provide information of automation status and intention via HUD where possible.

Differences between User Preference and Rankings of Usefulness

Performance is more important than preference, so need to make such that the takeover protocol elicits the best performance from the driver. Should not be irritating and frustrating though.

Characteristics of Modality

Capitalise on multimodality, such as presenting important information visually, auditorily, and haptically.

Synchronise Multimodal Cues - Combining or Single Modality

Need to decide if multimodal cues are presented together or in an escalating manner. Suggest escalating for non-emergency situations and together for emergency situations.

Longitudinal Studies

Drivers should be brought back into the simulator daily over the course of a week/ month to see how their behaviour adapts to the system. The average commuter drive lasts about 22 min on a motorway.

 
Source
< Prev   CONTENTS   Source   Next >