Angelos Amditis, ICCS, email@example.com Evangelia Portouli, ICCS, firstname.lastname@example.org Katia Pagkle, ICCS, email@example.com
Timing and duration of tests
2009 – 2011
Location(s) of tests
- Continental test track in Regensburg [ARC]
- Volvo test track in Hällered [AQuA, part of AGD]
- Truck simulator in Gothenburg, Volvo Tech [part of ADG]
- Volkswagen Proving Ground in Ehra, Lessing [TAP]
- Haldex test facility in Arjeplog of northern Sweden [Brake by wire truck]
User assessment tests Würzburg, Braunschweig
A. Highly automated driving functions (for public traffic) aiming at continuous driver support and improved road traffic safety:
- Automated assistance in roadworks and congestion [ARC; passenger car]:
This function applies highly automated driving in roadwork areas on highways. The vehicle speed is automatically adapted to the statutory speed limits and the vehicle is kept in safe distance to front and side vehicles and stationary objects. In case the system can not handle the situation, e.g. missing or destroyed lane markings, the driver is advised to take over at least part of the vehicle control. A stepwise transfer of the driving task is applied in this case. If the driver does not react properly, the system decelerates the vehicle according to the situation. In case a very critical situation inside the roadwork occurs (e.g. a vehicle in the right lane coming too close to the own vehicle) due to the low distances to other vehicles and the narrow lanes, the system may intervene, e.g. by emergency braking.
- Automated queue assistance [AQuA; heavy truck]:
This function supports the driver on motorways by integrated longitudinal and lateral control. This means that the system continuously supports the steering, accelerating and braking of the vehicle. The purpose of the automated queue assistance is to relieve the driver of the monotonous tasks associated with driving a truck in low speeds and in congested traffic situations, hence driver-underload situations.
- Temporary auto-pilot [TAP; passenger car]:
This function supports the driver on motorways and motorway similar roads with different levels of automation in longitudinal and lateral control of the vehicle at speeds between 0 and 130 km/h. TAP is intended to support the driver in monotonous traffic situations like traffic jams or monotonous long distance driving where s/he can experience work underload which can lead to a lack of focus and increased accident risk. In the highest level of automation, steering, accelerating and braking is completely managed by TAP. This highest level of automation is activated only if certain boundary conditions are fulfilled, e.g. the vehicle is driving on a motorway with less than 130 km/h. If these boundary conditions are not fulfilled, a lower level of automation is offered to the driver. Lower level of automation means that the driver can activate other assistance systems, like Adaptive Cruise Control and/or Heading Control.
- Active green driving / energy optimizing co-pilot [AGD, hybrid bus application]:
In this function the driver always controls the vehicle. A Human-Machine Interface (HMI) is used to coach the driver with the aim to reduce the fuel consumption and pollutions. ADG was demonstrated in a Volvo bus consisting of a parallel hybrid. It has been demonstrated that this powertrain concept can reduce the fuel consumption considerably. The demonstrator bus in the green vehicle application was equipped with sensors covering the area in front of the vehicle to foresee the vehicle movement in the longitudinal direction. The Volvo bus in HAVEit also was equipped with several perception sensors to foresee the vehicle movement. The preview information from the sensors was used in the powertrain controller, where decisions such as powersplit between Diesel and electric machine and Diesel on/off are determined. With the preview information it is possible to plan ahead and to better make the decisions mentioned above.
Also HAVEit designed, developed and implemented: B. Highly automated vehicles for safety architecture validation:
- Joint system driver / co-system (implemented and tested in simulators and test vehicle). It is built of:
- A perception layer including the vehicle sensors to the outside environment and to the driver.
- A command layer including an intelligent co-pilot system and a mode selection and arbitration unit (MSU).The co-pilot is based on command generation utilizing trajectory and maneuver based automation.
- An execution layer including the controllers for longitudinal and lateral control. This layer includes experimental controllers with special regard to the stability in automation transitions.
- A driver interface including the primary driving task interface like steering wheel and gas pedal, and specific HAVEit interfaces like automation level switches.
- Brake-by-Wire Truck for open roads (an electrically controlled brake system, intended for actuation of electromechanical disc brakes that control the clamp forces by an electric motor)
- Architecture migration demonstrator [AMD]
The latter is not thoroughly reported here. However more details may be included if deemed helpful.
Level of automation tested
SAE0 to SAE3
Tested use cases
The testing of the full systems included both stand-alone testing of each system component as well as of the complete systems. The technical tests involved situations where the functions should be activated. These where performed mainly in test tracks with semi-realistic scenarios
Highly Automated vehicles for public roads: Automated Assistance in Roadwork and Congestion [ARC]:
- Traffic Jam
- Vehicle in Front
- Speed limitation
- Presence of an adjacent road
- Driving through a construction site (in Semi Automated & Highly Automated modes)
- Right overtake
- Critical situation
- Critical lane change
- Prevention of curve over speed
- Minimum Risk State
Automated queue assistance [AQuA]:
- AQuA activation (by button)
- AQuA deactivation (by button or by brake pedal)
- AQuA lane change
- AQuA minimum risk state
Temporary autopilot [TAP]:
- Pilot function activation by the driver
- Automatic deactivation of pilot function caused by freeway
- Automatic deactivation of pilot function caused by lane markings
- Automativ deactivation of pilot function caused by driver in the loop assessment (Minimum Risk Manoeuvre)
- Stop & Go in a traffic jam
- Full driving test with a complex scenario
Active Green Driving [AGD]:
- Predicted deceleration and acceleration (divided into an energy management part and a driver coaching part since they could be operated independently of each other)
- Predicted speed limits
- Predicted downhill (uphill) driving
- Congested driving situations
Tested transport system
Passenger cars Trucks Bus (hybrid)
Purposes of testing
- Assessment of user (driver, traveller, etc.) acceptance, usability, take up, etc.
- Technical assessment, proof of concept (incl. vehicle, background support systems such as communication)
- human factors / interaction design. During the course of the HAVEit project eight human factors studies were conducted by three partners. In the first study phase, general questions were addressed to validate the preliminary design of the Joint System. Results of the findings by the four studies on the preliminary Joint System design were used to improve the Joint System design. With this improved design further studies were undertaken in the second study phase to address open design questions and to evaluate the final design.
Definition of baseline
The validation was focused more on the technical part and not on the human factors. The methodology followed in the HAVEit project was the following:
- Step 1: Validation by simulations
The validation of the Joint System concept was conducted in a simulation environment using the simulation software SILAB provided by WIVW. WIVW defined a common simulation platform which allows the integration of the different functionalities of highly automated driving in HAVEit. Further, WIVW defined and implemented a set of test scenarios which were used for system evaluation. Studies about the relevant questions were conducted in the driving simulator with motion system of WIVW in Wurzburg and the SMPLab at DLR. While DLR mainly concentrated on the transition and HMI concepts for the generic Joint system, WIVW developed a driver state assessment module which was used as input for the Mode Selection Unit. The results from these simulator studies were used to infer general Joint System principles and to develop a Generic Joint System demonstrator implemented in the FASCar demonstrator. Furthermore, the results were adapted to the HAVEit highly automated vehicle applications.
- Step 2: Component validation
Components including interfaces were precisely described in the specifications phase. Suppliers validated all components to be delivered to the vehicle owners with respect to these specifications prior to delivery.
- Step 3: Validation by "rapid prototype vehicle" to be used in restricted environment
The most important tool for the validation was the joint system demonstrator vehicle. This vehicle was based on the DLR research vehicle FASCar and was equipped with a mechanically decoupled steer-by-wire system and electronic interfaces to brake and throttle with full authority. Sensors and processing algorithms such as data fusion were installed in the vehicle and demonstrated at the end of the project. Demonstration took place on closed test areas. Additional to validating the technical specification, WIVW and DLR performed usability testing and conducted a user assessment of the complete system as part of the validation. Results include video footage, numerical data and questionnaires.
- Step 4: Validation by demonstrators
Finally, the highly automated vehicle applications were validated on demo vehicles in controlled tests / test tracks (following the aforementioned set of test scenarios/use cases).
Method of testing
Controlled field tests, Driving simulator, Simulation, Test track
Test fleet, participants and environment
Number and make of vehicles
HAVEit functions were demonstrated with the following vehicles:
- A VW passenger vehicle equipped by Continental with a 360 degree view realized with serial production sensors like radar and camera (Automated Assistance in Roadworks and Congestion)
- Volvo Truck FH (Automated Queue Assistance)
- Volkswagen Passat 2.0TDI passenger car (Temporary Autopilot)
- Hybrid Volvo Truck (Active Green Driving)
Moreover, the following demonstrators were used:
- 2009 Volkswagen Passat Variant [Joint System Demonstrator]
- Volvo FH12 [Brake by Wire Truck]
- VW Passat implementing the Joint System on embedded automotive ECU (“Chassis and Safety Controller”, CSC) using AUTOSAR methodology and standard CAN bus communication [Architecture Migration Demonstrator]
Description and number of participants/drivers
Tested environment and facilities
The technical assessment tests were conducted mainly on test tracks, e.g.:
- Continental test track in Regensburg [ARC]
- Volvo test track in Hällered [AQuA, AGD]
- Volkswagen Proving Ground in Ehra, Lessing [TAP]
- Haldex test facility in Arjeplog of northern Sweden [Brake by wire truck])
But also in laboratory/simulation environment as explained hereafter.
Legal and ethical aspects
Duration of testing
Technical validation of highly automated functions:
TAP; Volkswagen Proving Ground: A full driving test with all driving scenarios has been done in the two-lane motorway at the Volkswagen Proving Ground in Ehra, Lessing (see Figure 71). The test track consists of two straight roads with length of about 800m, and two sharp curves with the curve radius about 300m (on the left side) and 200m (on the right side), respectively. In difference to the normal motorways, those curves are extremely sharp, can be found only for motorway exit or highways.
AQuA and AGD; Volvo test track Hällered: AQuA works on motorways and quite defined environment, the AGD bus runs in urban traffic with very cluttered environment, sharp bends, roundabouts etc. All Aqua scenarios of use were tested in test track runs. Some AGD scenarios were tested in the test track, while some of them were tested by simulation in a truck simulator.
ARC Continental test track in Regensburg All ARC scenarios of use were tested in test track runs.
Validation of optimum task repartition
Temporary Autopilot [TAP]: 32 mainly male drivers with a relatively high experience with assistance and automation, tested two different designs for automation mode transitions in a test vehicle of partner VW, driving 70 km on a German interstate, with a target speed of 120 km/h. The automation (TAP Temporary autopilot) was emulated by a hidden person (Wizard-of-Oz technique). Different variants of transitions of control especially regarding braking, steering and right overtaking were tested. The overall approach was rated as appealing, comfortable and easy. The expectations were largely compatible with the actual design of the co-system, and were strongly influenced by the ACC behaviour. The two tested variants of the co-system varied significantly in acceptance and estimated level of risk.
Input parameters and assumptions of simulation tests
Validation of optimum task repartition
All highly automated functions (except TAP): 32 participants, 12 female and 20 male drivers tested four prototypes of highly automated driving with transition schemes that were as close as possible to those currently under discussion for the demonstrator vehicles. The study was conducted in the motion based simulator of DLR. The scenario consisted of driving on a highway with a speed up to 140 km/h, 8 drivers each tested one prototype configuration (between-subject design). A majority of drivers was able to build up a correct mental model of the automation behaviour and transitions for highly automated driving. The evaluation of the four prototypes regarding the transitions did not significantly differ in most of the evaluation criteria. Hints for improvements were deduced from interviews the drivers gave after the test drives.
Study on drowsiness detection, WIVW simulator:
6 test drivers drove in Driver Assisted and 6 drivers drove in Highly Automated mode. The test took up to 2.5 hours in simulated night conditions with the goal to make the drivers sleepy. When drowsiness was detected, an escalation scheme was initiated starting with information and warnings. In case of highly automated driving it escalated up to a request of the cosystem to the driver to take over control again. The experiment proved to be sufficient to make drivers drowsy. The drowsiness monitor was proven to detect drowsiness. The design was not intended to keep drivers awake, but to help drivers to avoid drowsy driving. The drivers accepted the drowsiness monitoring quite well, even the transition of control back to the driver in case of highly automated (and drowsy) driving.
Study on driver distraction WIVW simulator:
12 drivers were driving up to 120 km/h on a highway with varying driving task demands. In parallel to the driving task, a secondary task was offered, emulating a menu navigation task. In case of distraction, an escalation was started with an information and warning message, including LED’s in the wind screen. If a continued distraction was detected while driving highly automated, a take over request was triggered. Both performance of the attention monitor and the acceptance of drivers were high. Drivers reacted to the interventions in a meaningful way. In critical situations they immediately interrupted a secondary task when a warning occurred. In this implementation, drivers did not perceive it as domination of the co-system when it forced them to do a transition to Driver Assisted when they were repeatedly detected as distracted and as ignoring the warnings. Drivers rated the interventions of the attention monitor even more justified in highly automated driving.
Moreover, validation of preliminary design by simulation was performed in the early project stages.
Specifications for the data sources
Data logging was not made public in details
Key Performance Indicators (KPIs)
Situational data available
Subjective data collected
Issues that affected the impact assessment
Active Green Driving [ADG]: The preliminary studies in the driving simulator, although not by professional drivers, show the difficulties in getting immediate acceptance, maybe since it challenges the driver‘s idea of fuel economic driving. The driver‘s HMI, i.e. display of DCS related information and advice and the haptic pedal, has also been tested with good result, but more on-road tests are needed in order to evaluate the fuel saving potential by AGD. Validation tests undertaken indicate a fuel saving potential of 6-8% (depending on drive cycle and driving style).
- Deliverable D61.1 Final Report (link: http://haveit-eu.org/LH2Uploads/ItemsContent/24/HAVEit_212154_D61.1_Final_Report_Published.pdf)
- Deliverable D13.1 Optimized and validated demonstration vehicles (link: http://haveit-eu.org/LH2Uploads/ItemsContent/24/HAVEit_212154_D13.1_Public.pdf)
- Deliverable D11.1 Function description and requirements (link: http://haveit-eu.org/LH2Uploads/ItemsContent/24/HAVEit_212154_D11.1_Public.pdf)
- Deliverable D33.3 Validation by simulation (link: http://haveit-eu.org/LH2Uploads/ItemsContent/24/HAVEit_212154_D33.3_Superfinal.pdf)
- Deliverable D.33.6 Validation of concept on optimum task repartition (link: http://haveit-eu.org/LH2Uploads/ItemsContent/24/HAVEit_212154_D33.6_Public.pdf)
Other things to report
|Method of testing||Controlled field tests +, Driving simulator +, Simulation + and Test track +|
|Purpose of testing||Assessment of user (driver, traveller, etc.) acceptance, usability, take up, etc. + and Technical assessment, proof of concept (incl. vehicle, background support systems such as communication) +|