DEGREE PROJECT, IN AUTOMATIC CONTROL , SECOND LEVEL

STOCKHOLM, SWEDEN 2015

System Integration Testing of

Advanced Driver Assistance Systems

ANDERS CIORAN

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING

 Abstract

A key factor to further improve road safety is the development and implementation of
Advanced Driver Assistance Systems (ADAS) in vehicles. Common aspects of the inves-
tigated ADAS’ are their abilities of detecting and avoiding hazardous traffic situations by
using sensor data and vehicle states in order to control the movement. As more complex and
safety critical ADAS are developed, new test methods have to be considered. This thesis
investigate how to test new ADAS from a complete vehicle level by considering aspects such
as suitable test environments and traffic scenarios, and thereafter compare the results with
existing testing methods. Different classifications of ADAS have been investigated and com-
bined with own classifications considering complexity and traffic safety aspects, have made
it possible to conclude and propose general test strategies for different ADAS.
 Sammanfattning

En viktig faktor för att fortsätta förbättra trafiksäkerheten är genom att utveckla och
implementera avancerade förarstödsfunktioner (ADAS) i fordon. Gemensamma aspekter
hos de undersökta ADAS är deras förmågor att detektera och undvika farliga trafiksi-
tuationer genom att nyttja sensordata och fordonstillstånd för att kontrollera fordonets
förflyttning. Nya testmetoder måste övervägas eftersom nyutvecklade ADAS är mer kom-
plexa och säkerhetskritiska. Detta arbete undersöker hur man kan testa nya ADAS från ett
helfordonsperspektiv, genom att bland annat ta hänsyn till aspekter såsom lämpliga testom-
givningar och trafikscenarier, och därefter jämföra resultaten med nuvarande testmetoder.
Olika typer av ADAS klassifikationer har undersökts och kombinerat med egna komplexi-
tets och trafiksäkerhets klassifikationer har gjort det möjligt att dra slutsatser och föreslå
generella teststrategier för olika ADAS.
 Acknowledgements

This master thesis was conducted at Scania AB, in the research and development depart-
ment REST, in Södertjäle, Sweden. I would like to thank and express my gratitude to my
supervisors at Scania, Tom Nyman and Stefan Ottosson for this opportunity and as well for
sharing knowledge, feedback and tips with me.
I would also like to express my gratitude to my supervisor and examiner at KTH,
Jonas Mårtensson for his helpful advices and discussions making this report possible.
Abbrevations

ABS Anti-lock Braking System

ACC Adaptive Cruise Control
ADAS Advanced Driver Assistance Systems
AEB Autonomous Emergency Braking
BSD Blind Spot Detection
DAS Driver Assistance Systems
ECU Electronic Control Unit
ESC Electronic Stability Control
GPS Global Positioning System
GUI Graphical User Interface
HIL Hardware-In-the-Loop
LCP Lane Change Prevention
LDW Lane Departure Warning
LKA Lane Keep Assist
TCS Traction Control System
TJP Traffic Jam Pilot
TJA Traffic Jam Assist
V2I Vehicle-to-Infrastructure communication
V2V Vehicle-to-Vehicle communication
V2X Vehicle-to-vehicle and vehicle-to-infrastructure
communication
VRUD Vulnerable Road User Detection

1
Contents

Contents 2

1 Introduction 4
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Advanced Driver Assistance Systems 7

2.1 Description of ADAS functions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Purpose of ADAS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Current DAS and ADAS Functions . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 DAS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 ADAS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Legislation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Future ADAS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Future Outlook of the Transport Sector . . . . . . . . . . . . . . . . . . . . . 12
2.7 Autonomous Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Testing ADAS Functions 14

3.1 Different Testing Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Tools and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 PRE-crash SCenario ANalyzer (PRESCAN) . . . . . . . . . . . . . . 16
3.2.2 Laboratory Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Different Vehicle Test Methods at Scania . . . . . . . . . . . . . . . . 16
3.2.4 AstaZero Test Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Certification Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 European New Car Assessment Programme (Euro NCAP) . . . . . . 18
3.3.2 RDW European Type Approvals . . . . . . . . . . . . . . . . . . . . 19
3.4 Testing Autonomous Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Classification of ADAS 20
4.1 Level of Driving Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Functional Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2
 4.2.1 Safety Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Complexity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Combined Risk Estimation . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Discussion and Conclusion of Which ADAS Function to Investigate . . . . . 26

5 Case Study 1:
Autonomous Emergency Braking 27
5.1 Functional Description of AEB . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 Aborting an AEB Intervention . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2 Camera and Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 Functional Testing Level . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Complete Vehicle Level . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Case Study 2:
Lane Change Prevention 32
6.1 Functional Description of Lane Change Prevention . . . . . . . . . . . . . . . 32
6.2 Testing Lane Change Prevention . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.1 Simulation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.2 No Simulation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Aspects to Consider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.1 A Special Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Integration Testing of ADAS 39

7.1 Combined ADAS Functional Testing . . . . . . . . . . . . . . . . . . . . . . 39
7.2 General Test Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3 Proposed Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3.1 The Testing Methodology Applied on Platooning . . . . . . . . . . . 44
7.4 Future ADAS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 Summary, Conclusion and Future Work 46

8.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliography 48

3
Chapter 1

Introduction

1.1 Background
The development of safety systems used in vehicles has been progressing throughout the
automotive history. In recent years, significant progress has been made, and a new era
has emerged with the introduction of Advanced Driver Assistance Systems (ADAS). The
introduction of ADAS has made it possible to further decrease road traffic deaths (Golias
et al., 2002), as conventional safety systems have reached their full potential (Gietelink, 2007).
There is no exact definition of ADAS, but a description of ADAS provided by Gietelink
(2007) is given as a vehicle control system that uses environment sensors to improve driving
comfort and/or traffic safety by assisting the driver in recognizing and reacting to potentially
dangerous traffic situations.
The concept of systems that aid the driver by autonomous intervention is already estab-
lished. These systems, known as driver assistance system (DAS), have been available since
1978 when the first electronic anti-lock braking system (ABS) was introduced. Development
has since then continued, with the introduction of e.g. electronic stability control (ESC) and
traction control system (TCS).
The DAS functions are characterized by the two different types of inputs; the vehicle’s
states and driver input. With ADAS, the environment state is introduced as a new type of
input, where environment sensors are able to detect objects located outside of the vehicle,
e.g. other vehicles, pedestrians and road infrastructure. By introducing these new types of
sensors, the level of complexity of the vehicle increases, which affects test and verification.
The main similarities between ADAS and DAS functions with respect to test and verification
can be found during final stages of the development, where both types of systems have
to be implemented in real vehicles and driven on roads. Because ADAS functions use the
surroundings as an input, recreating different types of traffic scenarios need to be considered.
Therefore, early stages of the development of ADAS functions rely on simulations as it is
not feasible to perform road tests at this stage (Abdelgawad et al., 2014). Another aspect
that requires the use of simulators is the increasing safety-critical functionality of ADAS
functions. E.g. autonomous emergency braking (AEB) and lane keep assist (LKA) can
perform actions that endanger drivers and other road users, but can also cause significant

4
material damage and should not be tested on roads before extensive simulations have verified
that the functions are reliable.

1.2 Problem statement

There are several aspects that need to be considered before implementing new ADAS func-
tions. One aspect is that new ADAS functions are more complex because of more advanced
algorithms and the use of new environment sensors. Furthermore, ADAS functions can con-
trol the full range of motion of the vehicle and can also perform more complex and safety
critical maneuvers, e.g. hard braking and autonomous steering.
Until now, individual ADAS functions have been tested and verified separately, where
the certification criterion are clear. By implementing multiple ADAS functions, interaction
and communication between functions will be present as different functions can influence the
same parts of the vehicle at the same time, such as vehicle movement and indicators.
Therefore, the need of test and verification from a complete vehicle perspective is in-
creasing, and refers to test and verification of the interaction and communication between
different systems and components in the vehicle. This is of vital importance, e.g. if both
AEB and adaptive cruise control (ACC) are implemented, there should be no doubt that the
AEB has full braking control in case of a potential collision, and should therefore override
all signals provided by the ACC.
This report will address issues in system integration test of both individual and multiple
interacting ADAS functions. The following will be addressed:

• How should system integration tests be designed for future ADAS functions that can
influence the same components and systems at the same time.

– Investigation of suitable test environments, where and how should the test be
conducted. The location can be within an enclosed area or on public roads.
The test environment can be either fully simulated or by using real vehicles.
Different types of tests conducted in real vehicles can be further divided into
partial simulation of sensors/environments or by not using simulations.
– How to design different traffic scenarios with satisfying test coverage.
– Investigation of possible conflicts that might arise during execution of multiple
ADAS functions.

• How current ADAS functions are tested during different stages of development, and
the impact in complete vehicle testing.

5
1.3 Method
Firstly, a literature study of ADAS will be conducted, with the aim of acquiring relevant
material on existing ADAS functions that are currently under development. As the study
progresses, parallel work and study of current ADAS test and evaluation methods will be
conducted.
In parallel with the literature study, interviews of persons working with development and
test of ADAS functions will be conducted in order to find differences and equalities of test
and verification during different stages of the development.
The second half of this project will focus on designing different test cases for ADAS
functions. One of the main purpose will be to categorize ADAS functions in order to both
determine dependencies between functions and to get an overview of the resources required
to test each function.

1.4 Report Outline

The following is presented by each chapter:

• Chapter 2: Advanced Driver Assistance Systems, introduces the reader to the

concept and workings of ADAS with current and future ADAS functions.

• Chapter 3: Testing ADAS Functions, presents different tools and methods used
for testing ADAS functions at different levels and development stages, together with
different organizations that certifies ADAS functions.

• Chapter 4: Classification of ADAS, presents different methods used for classifying

ADAS functions and conclusions that are based on a combination of the different
classifications.

• Chapter 5: Case Study 1: Autonomous Emergency Braking, presents a case

study of an already developed function that is available on the market.

• Chapter 6: Case Study 2: Lane Change Prevention, presents a case study of

an ADAS function that is currently under development, containing test methods found
in case study 1 and new proposed methods.

• Chapter 7: Integration Testing of ADAS, gives an overview and general test

strategies for testing multiple functions that influence each other.

• Chapter 8: Summary, Conclusion and Future Work, summaries the report

with a discussion and conclusions of how to test future ADAS functions, combined
with suggestions for future work.

6
Chapter 2

Advanced Driver Assistance Systems

This chapter presents the concept of Advanced Driver Assistance Systems (ADAS). Descrip-
tions and a functional decomposition of ADAS are provided, together with descriptions of
both current and future ADAS functions.

2.1 Description of ADAS functions

ADAS is a term used for describing systems or functions that support the driver in their
primary driving task (Knapp et al., 2009). Primary tasks are considered as input to the
vehicle that can influence the vehicle’s movement, which are: acceleration, braking and
steering (Geiser, 1985). The report Knapp et al. (2009) states that ADAS functions are
characterized by all of the following properties:

• Detect and evaluate the vehicle environment.

• Support the driver in the primary driving task.

• Provide active support for lateral and/or longitudinal control with or without warnings.

• Direct interaction between the driver and the system.

• Use complex signal processing.

Compared to the ADAS characterization presented in the report by Knapp et al. (2009),
a more general definition of ADAS will be used in this report. In this report the support to
the driver can be expressed in two different forms, either by warning/indicating and/or by
controlling primary tasks. Therefore, in this report an ADAS function is characterized by
the both properties:

• Detect and evaluate own vehicle states, as well as other vehicles states and/or the
surrounding.

• Support the driver by at least one of the following methods; warning/indicating or

influencing primary tasks.

7
 Figure 2.1: Functional decomposition of ADAS (Gietelink, 2007).

A functional decomposition of ADAS is visualized in Figure 2.1 and presents an overview

of the workings of ADAS functions. By combining information about the surroundings and
from driver input, an ADAS function can predict collisions and as well react to dangerous
maneuvers caused by the driver. The controller seen in Figure 2.1 is the actual ADAS
function which can provide information to the driver via a human-machine interface and/or
influence primary tasks via actuators. The most common environment sensors providing
data to ADAS functions are radars, cameras, lidarand GPS.

2.2 Purpose of ADAS Functions

The main purpose of ADAS functions is to aid the driver while driving, and therefore prevent-
ing accidents from occurring. This is achieved by the ADAS functions’ abilities of predicting
road traffic accidents in combination with warning the driver and/or seizing control over
primary driving tasks.
Road safety is a societal issue in the world, with approximate 1.2 million deaths occurring
every year on the world’s roads (World Health Organization. Violence and Injury Prevention
and World Health Organization, 2013). Improving road infrastructure and education are two
methods used for decreasing the number of fatalities, but a report from U.S. Department
of Transportation National Highway Traffic Safety Administration (2013) states that the
human error is a contributing factor in 90 % of all accidents.
Systems supporting the driver are therefore essential and could improve road safety by
reducing the main cause of road accidents. The main type of safety systems used today are
passive systems with the purpose of reducing the consequences after an accident occur, e.g.
seat belt and air bag. In a report by Gietelink (2007), current passive safety systems have
reached their full potential. Therefore, new safety systems have to be developed in order to
further improve road safety.

8
2.3 Current DAS and ADAS Functions
Research and development of ADAS functions have advanced in recent years. This section
presents different DAS and ADAS functions that are currently available for trucks.

2.3.1 DAS Functions

Anti-lock braking system (ABS)
The purpose of ABS is to prevent the wheels from locking up and avoiding loss of
traction during hard braking. With ABS, when the driver applies hard braking the
system uses wheel speed sensors to detect lock-ups and thereafter pulses the braking
in order to avoid lock-ups. This increases the traction and the tires can maintain grip,
which helps the vehicle to be able to be steered.

Electronic stability control (ESC)

The purpose of ESC is to improve the vehicle’s stability by reducing loss of traction.
This may occur when skidding during evasive maneuvers or by losing traction on
slippery roads. The ESC continuously monitors the driver’s steering input and can
detect when a driver is about to lose traction by detecting if the vehicle is pointed in
the intended direction. If the driver is about to lose control, the ESC automatically
applies individual braking to each wheel in order to help regain control over the vehicle.

Traction control system (TCS)

The purpose of TCS is to limit the wheels from spinning on slippery pavement. The
same wheel speed sensors used by ABS is also used by the TSC. The TSC compares all
wheel speeds with the other, and if one wheel is spinning more quickly than the others,
the TSC will automatically apply braking pulses to that wheel in order to reduce that
wheel’s speed. However, the TSC can also reduce engine power if individual wheel
braking is not enough.

2.3.2 ADAS Functions

Adaptive cruise control (ACC)
The purpose of ACC is to automatically adjust the vehicle’s speed in order to main-
tain a safe distance to another vehicle traveling ahead on the same lane. By using a
combination of own vehicle states and environment sensors such as radars, the ahead
vehicle’s velocity can be determined and the ACC can either increase or decrease the
velocity to keep a safe distance to the ahead vehicle.

Autonomous emergency braking (AEB)

The purpose of AEB is to avoid collisions caused by late braking and/or braking with
insufficient force. By using environment sensors, such as radars and cameras, the AEB
can identify potential collisions with objects and vehicles ahead. If a critical situation
is detected, the driver will be warned, and if no reaction from the driver is detected,
the AEB will brake to avoid a collision (Euro NCAP, 2015a).

9
Lane departure warning (LDW)
The purpose of LDW is to warn the driver in the cases of inattention, which is activated
if the driver unintentionally drifts toward the edge of the lane. An environment sensor
such as a camera is used for providing data to the LDW, which in turn provides both
audible and visual warnings to the driver (Euro NCAP, 2015c).

Platooning
Platooning is performed by driving multiple vehicles close to and behind each other,
and is a way of increasing road capacity and to improve the safety, efficiency and
mileage. Speed and distance control for each vehicle is done by using a longitudinal
control system combined with vehicle-to-vehicle communication (V2V). By using V2V,
the lateral distance between each vehicle can be decreased because the platoon can
perform collective braking or accelerations because of the small communication lag.

Scania Active Prediction

The purpose of Scania Active Prediction is to decrease the fuel consumption by adjust-
ing the vehicle’s speed depending on the topography. A combination of an advanced
cruise control system, GPS and topography data enables the vehicle to adjust the cruise
speed before an ascent or descent. Compared to ordinary cruise controls which tries
to maintain a given speed, regardless of climbing or descending a hill, Scania Active
Prediction can adjust the speed before an ascent or decent by using the momentum
and therefore able to decrease the fuel consumption.

Common aspects of the described ADAS functions are in the sensor types and the type of
primary driving tasks that can be controlled. The sensors are forward looking cameras and
radars, while the driving tasks that can be controlled are limited to braking and accelerating.
The last primary driving task, steering, cannot be controlled by current ADAS functions.
However, future ADAS functions described later in this chapter have the steering capability
and combined with current ADAS functions will be able to control the vehicle’s full range
of motion.

2.4 Legislation
The European Commission has presented improved safety measures for vehicles. This is a
part of a road safety programme with the intention of halving road deaths by 2020 (The
European Commission, 2010). The following safety systems will be mandatory in most of
the new trucks (The European Commission, 2009):

• Electronic Stability Control Systems (ESC) as from 1 November 2014.

• Automatic Emergency Braking Systems (AEB) as from 1 November 2015.

• Lane Departure Warning Systems (LDW) as from 1 November 2015.

10
2.5 Future ADAS Functions
Future ADAS functions will be more complex with increasing maneuver capabilities and the
vehicles will be equipped with additional sensors providing a larger amount of sensor data.
The functions will have access to the increasing amount of data about the surrounding,
more efficient object recognition algorithms and the new maneuver capability autonomous
steering.
With the introduction of autonomous steering, ADAS functions will be capable of con-
trolling the full range of movement. Future functions will not necessarily be completely
new and different from current functions, but most functions will be a fusion between exist-
ing functions, or a combination between existing functions with new functionality. Future
functions that are not yet available to the market are described below:

Lane Change Prevention (LCP)

The purpose of LCP is to avoid dead angle accidents and accidents caused by lane changing.
LCP works by two steps; firstly the driver is notified of vehicles that are located in parallel,
in an adjacent lane. Secondly, if the driver tries to change lane, the LCP will intervene by
applying a counteracting torque to the steering wheel in order to keep the vehicle on the
current lane and therefore interrupting the lane change. LCP is a fusion between the two
functions blind spot detection (BSD) and lane keep assist (LKA).

Traffic Jam Pilot (TJP)

The purpose of TJP is to aid the driver through highway traffic jams by controlling the
vehicle’s motion. TJP uses radars and cameras in order to keep the vehicle in the lane
and following the traffic rhythm by autonomous steering. This is a combination of the two
functions adaptive cruise control (ACC) and lane keep assist (LKA), in combination with
pedestrian and object detection systems.

Vehicle-to-vehicle and vehicle-to-infrastructure communication (V2X)

The purpose of V2X is to share information between vehicles and the infrastructure, e.g.
information about traffic jams, dangerous traffic sections, accidents, and weather conditions.
This makes it possible to calculate faster and more efficient traffic routes which avoids queues.
The V2X is a communication device and cannot control the movement because it can only
indicate and provide information to the driver and other ADAS functions within the vehicle.

Vulnerable road user detection (VRUD)

The purpose of VRUD is to detect and indicate the presence of nearby vulnerable road
users, e.g. pedestrians and bicyclists. Furthermore, the VRUD is able to attention and warn
the driver if a possible collision between a vulnerable road user and the vehicle is detected.

11
This is achieved by equipping the vehicle with cameras, radars and software that can detect
vulnerable road users.

2.6 Future Outlook of the Transport Sector

By developing and implementing new ADAS functions in vehicles is by itself an advancement.
However, by looking further and from a broader perspective in order to make the transport
sector more efficient, the vehicles have to be connected and communicate with each other.
This new technology is the cooperative Intelligent Transport Systems and Services (C-ITS),
which enables communication between vehicles and the traffic infrastructure (The European
Commission, 2013).
Communication devices are common and widely used within e.g. the aviation and rail-
road industries. With connected vehicles that are able to communicate with each other and
the infrastructure, such as the traffic control, different possibilities arise. The transports can
become more effective by communicating in order to make traffic smoother, avoid accidents
and to choose optimal traffic routes by avoiding traffic congestions.
In order to realize connected vehicles and to make sure that communication between
different vehicle manufacturers are possible, the European Commission has proposed a stan-
dardization of the Information Communications Technology by introducing a rolling plan for
ICT Standardization (The European Commission, 2015).
Enabling communications between all vehicles is a significant advance because traffic
congestion is a common problem in the world’s cities. Increasing the road capacity are in
most cases not possible or desirable, therefore the traffic have to become more efficient by e.g.
connected vehicles. This idea is not unique, but with the introduction of ADAS functions,
combined with ITS makes it possible to use existing roadway capacity more efficiently.

2.7 Autonomous Vehicles

By combining current and future ADAS functions, autonomous vehicles can be created.
However, different levels of autonomy exist as the meaning autonomous can differ. The level
of autonomy is based on which and to what extent the autonomous vehicle can handle differ-
ent traffic situations. Research in this area has been conducted in parallel by different vehicle
companies, achieving different progresses. A few advanced autonomous vehicles driven on
public roads are presented below:

Autonomous Audi A7 Concept

The Audi A7 concept relies on a combination of sensors to get a 360 degree view of its
surrounding (Audi, 2015). Using this information, the A7 can make lane changes and
passing maneuvers between speeds of 0 and 113 km/h. However, the concept vehicle has
limitations and is only capable of driving autonomously in highway situations. When
approaching more complex environments, such as city traffic, the driver is requested
to take control of the vehicle.

12
Google Self-Driving Car
With over 1.8 million kilometres autonomous driving on public roads, the Google self-
driving car is one of the most tested autonomous vehicle on public roads (Google, Inc,
2015). Google has created the self-driving car by retrofitting other model cars with
sensors and driverless software. In comparison with the Audi A7 concept, Google’s car
is able to handle some city traffic. However, the cars rely primarily on pre-programmed
route data and therefore extensive road mapping has to be performed in advance.

Conclusions of current semi-autonomous vehicles can be made. Firstly, the amount of

data that the vehicle’s systems need to handle is increasing because sensors e.g. cameras
generate large amounts of data which has to be transmitted and processed by the on-board
computer.
Furthermore, limitations in today’s autonomous vehicles exist. They are currently only
able to handle certain types of traffic situations and environments, usually predetermined.
As research continues, additional ADAS functions will be developed and a stepwise imple-
mentation of these functions will occur, thus making vehicles more and more autonomous.

13
Chapter 3

Testing ADAS Functions

3.1 Different Testing Levels

The product development process typically consists of different stages, with different aspects
being considered during the development. Scania’s system testing levels are presented in
Figure 3.1, which describes and visualizes different parts and levels.

Embedded Systems Test Levels

Requirement Documentation Test Executer Test Level
Market Customer
Requirements Acceptance Test
Combination of Complete Systems integration test group Complete Vehicle
Function
requirements System Test
Complete Function Complete Systems integration test group Complete Vehicle
Allocation
Vehicle Documentation Integration Test

Function Function owner, local test group

Function Requirements
Function Test

Part System System owner, local test group

Requirements Part System Test
Part System Part System System owner, local test group Part Integration
Interface
Documentation Test

System System owner,

ECU Documentation local test group
ECU System Test

Module Interface Developer, local Module

Documentation test group Integration Test
A communication
Module Developer
Code Documentation Module Test and test
environment model.
Module
development Not a process!

Figure 3.1: The V-diagram presents different testing levels used at Scania (Adenmark, 2015).
As the test level increases, the product is closer to completion.

In Figure 3.1, different testing levels used at Scania are visible. The figure visualizes
different types of testing levels, depending on the stage of the development. The lowest
testing level is code testing and as the development progresses, higher testing levels are

14
reached. This project focuses mainly on the high level complete vehicle testing, but the
functional level will also be investigated.
The main differences between the complete vehicle level and the functional level are that
in the functional level, only the ADAS function is tested and verified, e.g. that internal
signals from sensors and commands are correct within the function. While in the complete
vehicle level, the interaction between the ADAS function and the rest of the vehicle is tested
and verified. This types of tests can be conducted by activating other vehicle functions, and
at the same time activate the new implemented ADAS function in order to verify that the
communication and interactions works as expected.

Figure 3.2: Black box and Grey box setup

The complete vehicle level testing is a form of black and/or grey box testing, depending
on the conducted test and its purpose. In a report by Khan et al. (2012), three different
types of box testing methods are explained: white, black and grey. In black box testing,
the tester has no knowledge of the internal systems and only the fundamental aspects of the
system are tested by measuring input and output. Khan et al. (2012) further describe grey
box testing, in this case the tester has limited knowledge of the internal workings but can
measure internal signals at different locations within the system, thus having access to more
signal values.
Both black- and grey box testing are visible in Figure 3.2. As seen in the figure, in black
box testing, the tester can only examine the input and output, whereas in grey box testing,
the tester has access to measurement points within the box/function.
This refers back to complete vehicle testing when implementing new ADAS functions
in vehicles. In this case, both black- and grey box testing can be used. For example, by
verifying that the function has correct output and works as expected, then the black box
testing is sufficient. However, if the signals within the ADAS function are of interest, e.g.
sensor data or internal signals, grey box testing is necessary.

15
3.2 Tools and Methods
Different tools and methods that can be used for complete vehicle testing are presented in
this section.

3.2.1 PRE-crash SCenario ANalyzer (PRESCAN)

PreScan is a simulation software tool developed by TASS International (TASS International,
2015). In PreScan, different traffic situations and scenarios can be simulated, where different
surroundings, vehicle dynamics and sensors can be simulated together. This is very useful
during early development stages for both ADAS and non ADAS functions, as sensor models
and algorithms in functions can be tested from a complete vehicle level perspective (Gietelink
et al., 2004).
How PreScan is used will be briefly explained. The user starts by designing a road map,
together with the surroundings, e.g. lane markings, traffic signs and traffic lights. Thereafter
vehicles can be added to the road map, together with a trajectory. Vehicle dynamics is
thereafter added to each vehicle, and if needed, sensor models and ADAS algorithms. It is
also possible to induce sensor disturbance to the models in order to simulate e.g. darkness,
fogs, sun-blinding or snowing. When the user has set up the environment and traffic scenario,
the scenario can be simulated. Thereafter the data is collected and analyzed to determine if
the ADAS functions worked as supposed.
PreScan is therefore valuable during early development stages because the testing are
based on models, which are not as accurate as real vehicle testing. However, this tool is
powerful and makes repeatable testing of algorithms very fast on already created scenarios.

3.2.2 Laboratory Testing

Hardware-In-the-Loop (HIL) simulation is often used when testing electrical systems and is
performed by connecting real hardware with each other and thereafter simulates the envi-
ronment. In Scania’s HIL-lab, I-lab, actual electronic control units (ECUs) are connected
to each other using the real communication network. Scania’s HIL lab is based on HIL
simulators and real-time Automotive Simulation Models (ASMs) from dSPACE.
The main purpose of the HIL simulation is to test real hardware devices in a simulation
environment before implementing it in real vehicles. This is a powerful tool for performing
automated testing of the communication and signals between ECUs. Furthermore, the auto-
mated testing process enables a large variety of different vehicle configurations to be tested
efficiently.

3.2.3 Different Vehicle Test Methods at Scania

Two types of test levels used in real vehicles have been investigated at Scania. The investi-
gated levels are the functional level and the complete vehicle level.

16
Functional Testing
In the functional level, the main purpose is to test certain systems, e.g. an ADAS function
and its internal components and signals. This is carried out by equipping a vehicle with
necessary sensors and algorithms needed for the function to work. The first step is to test
and verify that sensor data match the reality. It is performed by recording the road while
performing tests. The driver can then compare the recordings with sensor data to verify
that the sensor data correspond with the surroundings.
Furthermore, raw sensor data from certain types of sensors can be recorded and saved.
This makes it possible to perform regression tests of new algorithms and software on already
saved data, in order to verify that new functionality works as expected. Radar sensor data
can and is often saved for the above mentioned purpose. In the functional level, sensors
are often tested separately to examine the performance, thereafter the different sensors are
merged and the complete ADAS function is tested.

Complete Vehicle Testing

The main purpose of the complete vehicle testing is to test and verify that the interaction
and communication between the vehicle and the ADAS function is working correctly. This
is usually performed by equipping a vehicle with the complete ADAS function and then
performing tests using two different methods. The ADAS function is either tested as is, or
by simulating parts of the function while driving.

Figure 3.3: Schematic overview of two methods used when testing ADAS functions in real
vehicles. The coordinator is the vehicle’s main ECU that has access to all vehicle systems,
including ADAS algorithms.

A schematic overview of the two different methods is visible in Figure 3.3. The left figure,
Figure 3.3a, visualizes the complete ADAS function implemented in a vehicle, thereafter tests
are conducted in specific surroundings and traffic situations, depending on the purpose.
In Figure 3.3b, the sensors are still on the vehicle, but not connected to the coordinator.
Instead, sensor data is sent from a simulation script, and at the same time, the script receives
information about the vehicle’s states. The script is also connected to a GUI (Graphical User
Interface), in which different types of objects and situations can be created. Radar data is

17
often simulated in order to emulate other vehicles and their velocities and positions when
performing tests.
This is a powerful tool as repeatable tests of different traffic scenarios can be performed
without interactions between real vehicles. Therefore, one of the main advantage is that tests
of dangerous situations can be simulated instead of risking injuries and vehicle damage.

3.2.4 AstaZero Test Site

AstaZero is an open test site and was constructed for the development, testing and certifi-
cation of active safety systems. The test site is located outside of Gothenburg, Sweden, and
is the first full-scale test environment for future road safety (AstaZero, 2015).
The test site consists of four different environments: rural road, city area, multi-lane road
and a high-speed area. Each environment can be used for testing different scenarios in a
repeatable and structured manner. AstaZero also provides communication technologies that
can be used for vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication.
Other advantages of the AstaZero test site are that dynamical environments can be
tested, such as traffic lights, changeable traffic signs and different types of line markings and
sidewalks depending on preferences.

3.3 Certification Organization

Different parts of the world have different new car assessment programmes. The Global
New Car Assessment Programme (Global NCAP, 2015) presents that the main purposes
are to conduct independent research and testing programmes that will assess the safety
and environmental characteristics of motor vehicles. Global NCAP lists different regional
assessment programmes such as the European, Asian and North American. In this project,
only the European new car assessment programme (Euro NCAP) has been examined.

3.3.1 European New Car Assessment Programme (Euro NCAP)

The Euro NCAP is a performance assessment programme where the safety of vehicles are
assessed by a five star rating system. Currently, Euro NCAP have released protocols for
the following four areas: adult occupant protection, child occupant protection, pedestrian
occupant protection and safety assist.
The last protocol, the safety assist (Euro NCAP, 2015b), is most relevant for this project,
and will be briefly explained. In the safety assist protocol, the following types of ADAS
functions are presented:

• Speed Assist Systems,

• AEB Inter-Urban Systems,
• Electronic Stability Control,
• Lane Support Systems.

18
Each function is presented with an introduction and description, thereafter requirements,
criterion and scoring information is available. This information is detailed and comprehen-
sive, and makes it clear how the vehicle is assessed. The different ratings are not presented
in this report, but can be found in the Euro NCAP (2015b) safety assist protocol. This
document is informative for vehicle manufacturers when designing different safety systems
corresponding to different ratings.

3.3.2 RDW European Type Approvals

When a vehicle is first registered in an EU Member State, that vehicle must have a European
type-approval. RDW issues these type-approvals and also issues certificates for the following
ADAS functions:

• Advanced Emergency Braking system (AEB)

• Lane Departure Warning System (LDW)

• Electronic Stability Control (ESC)

The certification is based on EU-regulations, where detailed information of how the dif-
ferent functions are required to behave during different situations is presented. RDW’s test
site is located in the Netherlands and is used by Scania for certifying ADAS functions and
is the last step before market release.

3.4 Testing Autonomous Vehicles

By combining multiple ADAS functions, the vehicles become more autonomous. Previously
in this chapter, different methods and tools used to test ADAS functions from a complete
vehicle perspective was presented. During the development process, different types of tests
are conducted when testing different aspects.
While developing autonomous vehicles, test sites like AstaZero will be of importance. In
the test site, different traffic environments exist and make it easier and safer to test different
traffic scenarios compared to setting up and performing test cases on public roads.
Safety aspects of the test driver need to be considered, e.g. should the test driver be in the
vehicle and have access to a kill switch, or should the vehicle be completely remote controlled.
These types of safety aspects have to be considered for different levels of autonomous vehicles.
Furthermore, real-time simulation of sensors while driving is a powerful tool as it in-
creases the safety and make fast repeatable testing possible. The simulation combined with
test sites like AstaZero gives a good platform when testing autonomous vehicles during the
development. However, the need of real vehicle functional testing still exists i.e. where no
simulations are used, should also be conducted in enclosed environments, such as at As-
taZero. But, before conducting real tests on public roads, the above mentioned methods
give a good foundation for safer and more efficient testing methods.

19
Chapter 4

Classification of ADAS

This chapter presents two types of classifications. Firstly, the level of driving automation
describes how automated the vehicles is. Secondly, individual ADAS functions have been
classified where complexity and safety aspects have been considered and thereafter combined
into a combined risk estimation.

4.1 Level of Driving Automation

By implementing ADAS functions that can control primary driving tasks, an automation
system is created. This leads to the issue of driving responsibilities, whether the driver or
the system is responsible for the safety. The level of driving automation consists of different
levels, where different driving responsibilities between the driver and the system are defined.
Three organizations have defined the level of driving automation differently, where the
definition of each level differ slightly and the total number of levels are not the same. How-
ever, the same structure is used, where low levels correspond to high human responsibilities,
and with increasing automation levels the safety responsibilities shifts from the driver to the
system. The three presented organizations are; BASt, NHTSA and SAE.
Bundesanstalt für Straßenwesen (BASt)
The bundesanstalt für straßenwesen (BASt) is a research institute and a part of the
German government with focus in the field of road engineering. In 2012, BASt pre-
sented five different levels of automation (Tom M. Gasser et al., 2012).
National Highway Traffic Safety Administration (NHTSA)
National Highway Traffic Safety Administration (NHTSA) is a branch under the U.S.
Department of Transportation, with the responsibilities of reducing deaths, injuries
and economic losses resulting from motor vehicle crashes. In 2013, NHTSA defined
five different levels of automation (NHTSA, 2012).
Society of Automotive Engineers (SAE)
SAE International is a global association of engineers and technical experts in various
industries, with focus on the automotive industry. In 2014, SAE presented six levels
of driving automation in the issued SAE Standard J3016 (2014).

20
 driving task.

These levels are descriptive rather than normative and technical rather than legal. They imply no particular order of market introduction.
Elements indicate minimum rather than maximum system capabilities for each level. A particular vehicle may have multiple driving
automation features such that it could operate at different levels depending upon the feature(s) that are engaged.

System refers to the driver assistance system, combination of driver assistance systems, or automated driving system. Excluded are warning
and momentary intervention systems, which do not automate any part of the dynamic driving task on a sustained basis and therefore do
not change the human driver’s role in performing the dynamic driving task.

Execution of Fallback System

Monitoring
SAE Steering and Performance Capability
Name Narrative Definition of Driving
level Acceleration/ of Dynamic (Driving
Environment
Deceleration Driving Task Modes)
Human driver monitors the driving environment
the full-time performance by the human driver of all

0 No
Automation
aspects of the dynamic driving task, even when enhanced
by warning or intervention systems
Human driver Human driver Human driver n/a

the driving mode-specific execution by a driver assistance

system of either steering or acceleration/deceleration using

1 Driver
Assistance
information about the driving environment and with the
expectation that the human driver perform all remaining
Human driver
and system
Human driver Human driver
Some driving
modes
aspects of the dynamic driving task
the driving mode-specific execution by one or more driver
assistance systems of both steering and acceleration/

2 Partial
Automation
deceleration using information about the driving
environment and with the expectation that the human
driver perform all remaining aspects of the dynamic driving
System Human driver Human driver
Some driving
modes

task
Automated driving system (“system”) monitors the driving environment
the driving mode-specific performance by an automated

3 Conditional
Automation
driving system of all aspects of the dynamic driving task
with the expectation that the human driver will respond
appropriately to a request to intervene
System System Human driver
Some driving
modes

the driving mode-specific performance by an automated

4 High
Automation
driving system of all aspects of the dynamic driving task,
even if a human driver does not respond appropriately to a
request to intervene
System System System
Some driving
modes

the full-time performance by an automated driving system

5 Full
Automation
of all aspects of the dynamic driving task under all roadway
and environmental conditions that can be managed by a
human driver
System System System
All driving
modes

Copyright © 2014 SAE International. The summary table may be

freely copied and distributed provided SAE International and J3016
are acknowledged as the source and must be reproduced AS-IS.
Figure 4.1: Summary table of SAE international’s J3016 driving automation (SAE Standard
Key definitions in J3016 include (among others):
J3016, 2014).
Dynamic driving task includes the operational (steering, braking, accelerating, monitoring the vehicle and roadway) and tactical
(responding to events, determining when to change lanes, turn, use signals, etc.) aspects of the driving task, but not the strategic
(determining
SAE destinations and waypoints)
international’s levels ofaspect
drivingof theautomation
driving task. is visible in Figure 4.1, and presents proper-
Driving
ties mode
and is a type ofofdriving
aspects the scenario with levels,
different characteristic
as dynamic
well asdriving task requirements
an overview. The (e.g., expressway
level merging,automation
of driving high speed
cruising, low speed traffic jam, closed-campus operations, etc.).
defined by NHTSA and BASt differs slightly, where the number of levels and level naming dif-
Request to intervene is notification by the automated driving system to a human driver that s/he should promptly begin or resume
fers. However, the definitions are similar, and have been mapped in Figure 4.2 to correspond
performance of the dynamic driving task.
to the SAE levels.
Contact: SAE INTERNATIONAL +1.724.776.4841 • Global Ground Vehicle Standards +1.248.273.2455 • Asia+86.21.61577368

P141661

Figure 4.2: Comparison and overview of the different notations for the different levels of
automation (SAE Standard J3016, 2014), (Tom M. Gasser et al., 2012), (NHTSA, 2012).

21
 One of the key aspects of these different levels of driving automation is the transit from
level 2 to 3, where the driver’s role shifts from safety control to supervisory control due to
level 3’s definition where the system is responsible for monitoring the driving environment.

4.2 Functional Analyses

Functional analyses have been conducted in order to get a better overview and find depen-
dencies between different ADAS functions. Each function has been analyzed with respect to
two different aspects, safety and complexity, and are presented further in this chapter.
The materials used for the functional analyses’ are mainly based on interviews with Scania
employees, where information about current and future development of ADAS functions was
acquired. Current and future technology, such as different sensors that can be used by many
different functions was the essential part. Two types of sensors, radars and cameras were
considered of significant importance and will provide data to many functions, therefore these
types of sensors will be further investigated.

4.2.1 Safety Analysis

The purpose of the safety analysis is to evaluate the traffic safety risks of maneuvers that
each function can execute. Two aspects are considered in the safety analysis; either the
function is activated during correct situations, or not. An example of a function that is
activated during a wrong situation is if the AEB is activated by another vehicle located in
the road’s shoulder and therefore not on a collision path.
The safety analysis is presented in Figure 4.3 and each function has been analyzed by
considering the following aspects:

• Which types of vehicle movement can be controlled,

• Which types of damages can occur during execution,

• The danger of execution during wrong situations.

22
 Figure 4.3: Safety analysis of different ADAS functions.

The safety analysis seen in Figure 4.3 consists of five different sections. Each section
corresponds to different types of vehicle movement that can be controlled. Thereafter, ADAS
functions have been placed in the corresponding section, where functions located to the left in
Figure 4.3 have a lower traffic safety risk, and functions with a higher safety risk to the right.
Primary driving tasks are the main aspects that were considered when making the analysis
and the safety risk increases in the following order: braking, acceleration and steering. Each
section in Figure 4.3 is explained below, starting with the lowest traffic safety risk:

• Display: The function provides audible and/or visual indications and cannot affect
vehicle movement. For example warnings and signals in the dashboard.

• Soft braking: The function can influence the brakes by performing soft braking. E.g.
by providing a small braking force when the vehicle is approaching a curve too fast.

• Hard braking/Acceleration: The function can control the acceleration and/or the
brakes. E.g. adaptive cruise control or hard braking in order to avoid an accidents.

• Steering: The function can control the steering, e.g. traffic jam assist and lane change
prevention.

• Complete: The function can control the full range of motion, i.e. autonomous vehi-
cles.

There is a leap from hard braking/acceleration to the steering capability because by in-
troducing functions that can control the steering, the driver’s role can change from driving
to supervision. When the driver does not have an active part in the vehicle’s movement, mo-
ments of distractions might arise. Another aspect is that the driver’s reaction time increases
if no active steering is needed, which also increases the possibility of an accident to occur if
e.g. an ADAS system is failing.

23
4.2.2 Complexity Analysis
The main purpose of the complexity analysis is to get an overview of the dependencies
between ADAS functions and to determine which hardware is needed when implementing
new functions. Therefore, this analysis does not take the algorithm’s complexity into account,
but only the hardware aspects.

Figure 4.4: Complexity analysis of ADAS functions.

The complexity analysis is presented in Figure 4.4 and each function has been analyzed
by considering the following aspects:

• Which hardware is/are needed,

• Dependencies between functions.

The complexity analysis seen in Figure 4.4 consists of five different sections, each section
representing different types of hardware that are needed in order to implement respective
ADAS function. Furthermore, many functions in Figure 4.4 are connected by arrows, the
arrows visualize that dependencies between functions exists. In most cases, more complex
functions found to the right in Figure 4.4 depends on other less complex functions.
Taking lane change prevention (LCP) as an example, in order to develop and implement
LCP, both lane keep assist (LKA) and blind spot detection (BSD) need to be developed. In
turn, these functions rely on the implementation of new hardware such as a steering actuator
and radars. The complex analysis in Figure 4.4 may also be used as a guide when choosing
in which order to develop new ADAS functions.

24
4.2.3 Combined Risk Estimation
Both the analyses traffic safety risk and complexity have been combined into a risk estimation
diagram in order to get a better overview and able to draw conclusions. The combined risk
estimation diagram is visible in Figure 4.5. Each section from the two analyses has been
given a number, ranging from one to five, where one represents the lowest risk/complexity.
The functions have thereafter been placed in their appropriate place in the diagram, together
with a number to the right. This number represents the combined risk estimation and is
calculated by multiplying the function’s two numbers from each analysis.

Figure 4.5: Figure of the combined risk estimation. The number to the right of each func-
tion represents the product of the two numbers from each analyses safety safety risks and
complexity.

By assigning a total risk estimation number to each function, it is possible to get an

overview of how much effort that is needed when developing the functions. A higher number
represents a higher traffic safety risk and complexity, therefore more resources have to be
allocated when developing such functions.
By analyzing the needed resources, decisions of which functions to focus more on and
whether there are enough resource capacity can be taken.

25
4.3 Discussion and Conclusion of Which ADAS Func-
tion to Investigate
One of the aims in this project is to investigate future ADAS functions and compare it to
already implemented functions. The analyses presented in this chapter have made it possible
to get a better overview and find dependencies between different functions, therefore making
it possible to determine which function to investigate. The following criterion have been
considered when deciding which ADAS function to investigate:

• The level of driving automation,

• Combined risk estimation analysis,

• Close in time with respect to development and implementation,

• Fusion between multiple ADAS functions.

Most ADAS functions that are currently available on the market are categorized as driving
automation level 1, seen in Figure 4.1, and in the lower part of the combined risk estimation.
The chosen function to investigate should therefore be more complex and have a higher
combined risk estimation, compared to currently available functions. Lane change prevention
(LCP) has been chosen because it is a fusion between lane keep assist (LKA) and blind spot
detection (BSD), LCP is therefore more complex and has a higher combined risk estimation,
and can be seen in Figure 4.4 and Figure 4.5.
Another aspect which was considered when choosing LCP is that the development of
both BSD and LKA are progressing in the industry, and therefore making LCP relatively
close in time with respect to development and implementation. One example is the active
blind spot assist developed by Mercedes-Benz (2015).

26
Chapter 5

Case Study 1:
Autonomous Emergency Braking

This chapter presents an existing ADAS function developed at Scania. The function
autonomous emergency braking (AEB) is one of the newest function at Scania and has also
been extensively tested. Detailed information about how AEB works, together with how the
function has been tested at different levels are presented. Furthermore, important aspects
such as advantages and disadvantages during different testing levels are mentioned.

5.1 Functional Description of AEB

Autonomous emergency braking (AEB) is an ADAS function with the purpose of avoiding
accidents caused by late braking and/or braking with insufficient force, often caused by
unobservant drivers or during limited road visibility.
The workings of the AEB differs slightly between different vehicle manufacturers, however
a general procedure for the workings of the AEB is presented by the following four steps:

• Step 1, Identify critical situations: The AEB identifies critical situations by us-
ing data provided by mounted sensors, such as cameras and radars, together with
information about the vehicle’s states.

• Step 2, Warn the driver: After a critical situation is detected, the AEB warns
the driver that a collision might occur by a combination of both visual and auditory
warning-signals.

• Step 3, Soft braking: If the driver does not acknowledge the warnings, the AEB
will apply a soft braking to the vehicle, in order to further attention the driver.

• Step 4, Hard autonomous braking: At some point, even by applying maximum

braking force, an accident cannot be avoided. Slightly before this point, the AEB will
initiate hard braking in order to get the vehicle to a standstill within a certain safety
distance to the object in front.

27
Figure 5.1: Simplified overview of the AEB’s inputs and outputs. The radar and camera
provide data to the vehicle’s main computer, the coordinator. The coordinator has access
to its own vehicles states and the AEB’s algorithms, and is able to send commands that
influence brakes and indicators.

The AEB requires two different types of inputs to work properly. The two types are
states from surrounding vehicles and the own vehicle’s states. A simplified overview of the
inputs and outputs from the AEB is visible in Figure 5.1. The camera and radar provide
information about surrounding vehicles. The main computer, the coordinator, provides own
vehicle states such as velocity, heading, driver inputs and general information about the
vehicle. The AEB’s algorithms can access this information from the coordinator and send
commands for controlling brakes and indicators.

5.1.1 Aborting an AEB Intervention

The AEB intervention can be overridden and deactivated by the driver. To do this, the
driver must indicate to the vehicle that he or she is aware of the situation. The driver can
abort an AEB intervention by one of the following methods: brake, accelerate, activate the
turn signal or by turning the steering wheel to a collision-free path.

5.1.2 Camera and Radar

The AEB uses inputs from both a camera and a radar in order to detect other vehicles
and objects. The sensors are placed in the front part of the vehicle, pointing forward. By
combining data from both the radar and camera, the AEB is more accurate in detecting
both standstill and moving objects, compared with using only one type of sensor because
each sensor has different advantages and disadvantages.
The main advantage of the radar is the ability of accurately detect moving objects, their
heading and velocity, unlike the camera’s main advantage of object recognition. Therefore,
it is sufficient to only use the radar for detecting moving vehicles, but for standstill vehicles,
both the radar and the camera need to be used.

28
Figure 5.2: Schematic overview of the radar unit’s inputs and outputs. Raw radar data
is both recorded and saved by a recording device and also sent to the object recognition
algorithm which identifies other vehicles.

An overview of the inner workings of the radar unit is visible in Figure 5.2. The figure
presents that the physical location of the detection algorithms is within the radar unit and
that the raw data can be recorded and saved. This makes it possible to perform regression
tests of new radar algorithms on already recorded data. In the current set up, it is not
possible to record raw camera data, however the principle is the same, and the camera’s
detection and object recognition software is enclosed within the camera unit.

5.2 Testing
This section presents an investigation of how the AEB has been tested during different stages
of the development at Scania. The two different testing levels functional level and complete
vehicle level have been investigated. In the functional testing level, the focus is on testing
the sensors, the AEB and its internal components, while in the complete vehicle testing, the
interaction between the AEB and the rest of the vehicle is tested and verified.

5.2.1 Functional Testing Level

Two different types of sensors used by the AEB, camera and radar, have been investigated
and is presented below, together with radar-camera fusion testing.

Radar
The radar unit and its detection algorithms are provided by a supplier. The radar detects
the closest vehicles and sends the following data about them: position, heading, velocity
and vehicle type. Therefore, the test at Scania verifies the radar’s capability of accurately
detecting the above mentioned aspects within specified tolerances.
The test is performed by equipping a vehicle with both the radar unit and a standard
camera for documentation purposes. Thereafter, the vehicle is driven in both enclosed areas
and on public roads while performing tests. The tester can then verify that the radar output
corresponds with the real world by comparing radar data with the recorded video.
As previously described, raw radar data can be saved and used later to regression test new
algorithms and software. Therefore, raw radar data from many different types of scenarios

29
and traffic situations are recorded and saved and is used in the future. The saved data can
later be transferred to a computer and is used for verifying new radar algorithms. This gives
the tester an efficient and powerful tool for both retesting and regression testing.

Camera
The camera unit does not have the same ability as the radar unit, and cannot save raw
camera data. However, the schematics presented in Figure 5.2 is similar for the camera unit,
excluding the raw data recording device.
The verification of the camera unit is therefore more dependent on road testing and
similar to the radar testing, another camera is used to record the road for documentation
purposes. The camera’s algorithms can detect the following information about nearby vehi-
cles: position, heading, velocity and vehicle type.
Different types of situations are chosen when verifying the camera unit and its algorithms.
The purpose is often to test the object recognition and road line detection algorithms; in
addition the camera unit testing is often combined with radar testing. Furthermore, other
types of tests are performed, such as testing what happens when the camera is obstructed
or by placing the camera in front of a projector screen while projecting traffic scenarios.

Radar-Camera Fusion
The radar-camera fusion testing is performed by connecting both the radar and the camera to
the vehicle, together with another camera which is recording the road. The ADAS algorithm
is then implemented in the coordinator, which decides when to intervene by activating brakes
and/or warnings signals.
The purpose of the fusion testing is to verify that both the camera and the radar detect the
same vehicle states of nearby vehicles. One method that is used for testing the radar-camera
fusion is by driving the equipped vehicle towards standstill or moving balloon cars. This
verifies whether the AEB works correctly according to the functional description presented
earlier in this chapter, in section 5.1. However, test methods from both the functional and
the complete vehicle levels are overlapping in many cases, such as performing tests on public
roads or by using simulation tools.

5.2.2 Complete Vehicle Level

In the complete vehicle test level, the interaction and communication between the AEB
and the rest of the vehicle is tested and verified. The test is often performed to verify the
following three aspects; the AEB executes correctly during different traffic situations, the
driver can deactivate an AEB intervention and that new implemented vehicle functions and
configurations does not interfere with the AEB.
Two main types of tests are conducted; firstly the tests are conducted in enclosed areas
and thereafter on public roads because different surroundings are used for different purposes.
In the enclosed area testing, the focus is to provoke an AEB activation, while in public road
testing, the main focus is to test false positive error, i.e. if the AEB activates during wrong

30
situations. However, the public road testing also tests whether the AEB is activated during
correct circumstances or not.
The testing can either be performed without simulating sensors, or with the sensor simu-
lation tool described in subsection 3.2.3, which can simulate other vehicles. Simulating other
vehicles is often used when testing in enclosed areas because it makes fast and repeatable
testing possible. This is possible because by simulating other vehicles, many different test
cases can be performed by a single driver, compared to using multiple vehicles and drivers
which need to communicate and coordinate with each other while performing the tests.
When testing the AEB, a single driver can simulate vehicles in front and verify that the
AEB intervenes. This is then repeated by simulating other vehicles with different velocities
and positions. Another aspect that is tested is if it is possible to deactivate the AEB by
the methods described in subsection 5.1.1: brake, accelerate, activate the turn signal or by
changing direction.
Other aspects that can influence the sensors are considered, e.g. fuse malfunction, ob-
structing objects and low visibility conditions are tested to verify that the AEB deactivates
due to faulty sensor inputs. Vehicle characteristics and functions should also be considered,
e.g. if a trailer without ABS is connected to the tractor unit, then the AEB should remain
deactivated at all times due to the possibility of jackknifing when braking hard.
When implementing new vehicle functionality that could affect the AEB, regression tests
have to be performed. An example is when implementing a functionality that can influence
the same parts of the vehicle as the AEB, such as braking and dashboard commands, e.g.
the turn signal. Therefore, regression testing is necessary in order to verify that the AEB
still works correctly after implementing new functionality that may interfere with AEB
commands.

5.3 Conclusion
Several aspects of the AEB are tested in the different testing levels functional level and
complete vehicle level. This is positive as errors are more likely to be found when different
project groups are working independently in each of the testing levels. Other ADAS functions
also use the outputs from the radar and camera sensors, and therefore the testing performed
in the functional level can be adopted and used when testing other functions.
One of the main feature is the ability of simulating radar data, which makes test cases
repeatable and faster to perform. The simulation tool should therefore be further developed
for simulating multiple vehicles at the same time. An investigation for simulating raw camera
data should be conducted in order to perform repeatable and fast testing by implementing
it in the simulation tool.
The AEB is a medium safety critical function, seen in Figure 4.3, therefore false positive
testing is a part of the AEB testing. Much effort has been put into eliminating false positive
errors such as AEB activation during wrong situations that can cause accidents and surprise
the driver. E.g. if the vehicle behind does not have enough time to stop due to the unexpected
braking, or by having a driver that becomes confused and makes irrational maneuvers are
aspects that need to be considered when testing ADAS functions.

31
Chapter 6

Case Study 2:
Lane Change Prevention

The full discussion of why lane change prevention (LCP) was chosen for this case study is
presented in section 4.3. Briefly, LCP was chosen because it has a higher level of automation
and a higher combined risk estimation compared with already developed ADAS functions
such as the AEB.

6.1 Functional Description of Lane Change Prevention

Lane change prevention (LCP) is an ADAS function with the purpose of avoiding accidents
occurring when changing lanes, in many cases due to unobserved vehicles positioned in the
blind spot. The LCP is a combination and fusion between the two ADAS functions blind
spot detection (BSD) and lane keep assist (LKA).
The blind spot traffic scenario depicted in Figure 6.1 together with the following three
steps present the workings of the LCP:

• Step 1, Identification and indication

The BSD detects parallel vehicles located in the adjacent traffic lanes and indicates
this to the driver.

If the BSD indicates that another vehicle is located in parallel and in an adjacent lane, and
the driver tries to perform a lane change, the following will happen:

• Step 2, Providing warnings

Auditory and/or visual warnings will be activated in the cabin, either in the right or
left side depending on the direction of the lane change.
• Step 3, Counteracting the driver’s steering torque
If the driver does not abort the lane change maneuver while the warning is active, and
is still approaching the line markings, then the LCP will activate the LKA in order to
counteract the driver’s steering torque to keep the vehicle within the lane.

32
Figure 6.1: Two vehicles are traveling in paralleled with the same direction, in different
lanes. Vehicle 2 is positioned in the blind spot of vehicle 1.

The last step, step 3, is possible due to the use of LKA. LKA is activated by the LCP
in order to abort a lane change maneuver and to remain within the initial traffic lane. A
combination of both cameras and radars are needed for detecting objects and vehicles located
in parallel and closely in front. Alike the AEB, front looking camera and radar can detect
nearby vehicles and line markings, but the LCP requires side radars or other sensors that
are able to detect vehicles positioned along the truck’s side and in parallel.
The idea is to use LCP while driving on highways or on other major roads, as smaller
roads and city traffic implies complex situations that cannot yet be managed by the LCP.

6.2 Testing Lane Change Prevention

In this section, different methods that can be used for testing LCP are presented. Two
different types of testing methods are presented, and the difference between them is whether
simulation tools are used while performing the tests. Both methods have already been
presented in the previous chapter where AEB testing was investigated. Based on the inves-
tigated methods and the literature study, suitable test methods and surroundings for testing
LCP are suggested in this section.

6.2.1 Simulation Tools

Using simulation tools refers to simulating any part of, or the whole vehicle and its surround-
ings. Simulating tools are further categorized into complete vehicle simulation and sensor
simulation.

Complete Vehicle Software Simulation

PreScan, a software simulation tool described in subsection 3.2.1 can be used for creating
different virtual traffic scenarios and environments. Vehicles and their dynamics can be
modeled and included in the scenario, together with attaching sensor models of cameras and
radars to the vehicle. Thereafter, the LCP algorithms are included within the vehicle and
the tester can start simulating a scenario.
PreScan is initially used for testing and verifying LCP algorithms because the vehicle,
surroundings, sensors and scenarios are fully simulated. The scenario in Figure 6.1 can be

33
used for initial testing by having vehicle 1 performing a lane change maneuver towards lane
2. Before and during the lane change, the tester can verify that the indications, warnings
and interventions proceed according to the three steps in the functional description of lane
change prevention described in section 6.1.

Sensor Simulation
The concept of simulating sensors in real vehicles is presented in the complete vehicle testing
in subsection 3.2.3 and used for testing the AEB in subsection 5.2.2.
The method is to connect a computer to the vehicle’s CAN-bus and send simulated radar
data directly to the coordinator, as seen in Figure 3.3b. The main purpose is to verify
that the LCP behaves correctly to different radar output. By simulating the radar unit,
the communication between the radar and the rest of the vehicle is verified. Two different
environments have been considered and the test scenarios are the following:
• Enclosed area, test case 1

– Step 1, Start and remain stationary in the middle lane of a three-lane road.
– Step 2, Simulate another vehicle in parallel, in an adjacent lane.

The purpose of the enclosed area, test case 1 is to verify that the BSD works properly
at standstill and that it indicates that a vehicle is located in parallel. The simulated
vehicle should also be placed in the vehicle’s two blind spots located to the left and
right while performing this test case. If the BSD works properly by giving correct
indications, move on to the enclosed area, test case 2. If test case 1 is not successfully,
then the BSD algorithm needs to be reconsidered.
• Enclosed area, test case 2

– Step 1, Drive the vehicle in a straight line in the middle lane of a three-lane road.
– Step 2, Simulate another vehicle in parallel, in an adjacent lane.
– Step 3, Steer slightly towards the simulated vehicle.

The purpose of test case 2 is to verify that the whole LCP works properly. Firstly,
the BSD should indicate that a vehicle is located in parallel and thereafter activate
the auditory and visual warnings. Lastly, the LKA should activate and provide a
counteracting steering torque to the tester.
By simulating other vehicles, many different traffic scenarios can be created because the
simulated vehicle’s speed and relative distance can easily be changed to different values.
Furthermore, simulating multiple vehicles on both sides at the same time should be
performed in order to check that the indicators in both sides of the cabin can be active
at the same time. Another aspect to consider and to test is by simulating vehicles
that are approaching with substantial higher velocity in an adjacent lane. Changing
lanes in such circumstances is dangerous and the LCP should intervene. All of the
mentioned tests should be performed for the vehicle’s both sides.

34
 • Public roads
In public road testing, aspects that are difficult to recreate in enclosed area testing
are of interest, such as performing tests in sloped terrain, curves and during other
surroundings that might interfere, e.g. overhead signs, bridges and tunnels.
Testing on public roads should be performed after enclosed area testing and one of the
purpose is to further verify same aspects considered in the enclosed area testing, but
in different environments. However, test cases where the LKA is activated cannot be
performed when nearby public road users exist. When no other nearby road users exist
and in the above mentioned surroundings, the proceedings from the enclosed area, test
case 2 can be used carefully.
In both the enclosed area and public road testing, the BSD’s algorithms and the whole
LKA function can be verified. The tests are not performed when having real vehicles
nearby because the simulation tool is used to simulate nearby vehicles, therefore only
a part of BSD is verified. In comparison, no part of LKA is simulated; therefore the
whole LKA function is verified.

6.2.2 No Simulation Tools

The purpose of the road test is to test and verify that that the communication between the
LCP and the rest of the vehicle is working properly. Test cases used in AEB testing can also
be applied here, such as obstructing the sensors with objects and with faulty sensor outputs.
The following test cases are considered in order to cover different traffic scenarios:

• Enclosed area, test case 3

– Step 1, Start and remain stationary in the middle lane of a three-lane road.
– Step 2, Position another stationary vehicle in parallel, in the adjacent lane.

The purpose of test case 3 is to verify the BSD’s indications for both sides of the vehicle.
Additionally, two different types of tests should be performed by slightly changing this
test case. In step 2, replace the stationary vehicle and perform the test for each of the
following vehicle types: motorcycle, smart car, van and bus.
The second type of test is by still performing step 1, but in step 2, the parallel vehicle
should be making an overtaking maneuver. Different velocities should be tested and
the tests should also be performed with the different mentioned vehicle types.

35
• Enclosed area, test case 4
This test case is based on the traffic scenario in Figure 6.1, where two vehicles are
traveling in a straight line, in parallel and in the same direction. Vehicle 1 is equipped
with LCP and the procedure is the following:

– Step 1, Drive two vehicles in parallel with the same velocity, as seen in Figure 6.1.
– Step 2, Vehicle 1 makes a slow lane change maneuver toward vehicle 2 in lane 2.

This test case covers and tests all components of the LCP function. Firstly, the BDS’s
indications are tested and as the lane change maneuver begins, the warnings and the
LKA’s counteracting steering torque should activate.
The test case should then be slightly changed in order to perform a similar test. In
step 1, instead of driving in a straight line, both vehicles should be driven on a curved
road. This is necessary because curves are common in traffic roads, but also that when
driving in curves, the location of the blind spot differs slightly. By driving on curved
roads, the blind spot BSD’s detection algorithm is further tested because it now has
to take the curvature into consideration. Another aspect to consider on curved roads
is if the truck’s trailer is long, then the BSD might detect the own trailer as another
vehicle.

• Public roads
The testing on public roads can either be performed when other road users are nearby
or not. When no road users are nearby, test case 3 and 4 can be performed with great
care.
Only the BSD’s part of the LCP can be tested when other road users are nearby,
because testing the full LCP on unsuspecting road users can cause accidents. The
BSD is tested by driving normal in different traffic environments such as sloped terrain,
under overhead signs, on bridges and in tunnels to verify the BSD’s indications when
other vehicles are in the blind spot and/or in parallel in an adjacent lane.
Another aspect to consider is infrastructure and fixed installations such as poles, traffic
lights, traffic signs, guard rail, concrete blocks, buildings, traffic island etc. Testing the
BSD and its outputs when it detects fixed installations has to be performed by driving
nearby these installations and verify the outputs.

36
6.3 Aspects to Consider
The traffic surroundings are not static, therefore less common aspects and road situations
have to be considered. This section presents a few less common aspects that need to be
considered when testing the LCP.

• Different types of line and lane markings

There is no standard in line and lane markings, therefore the different sizes used in
different countries have to be taken into account.

• Long and different sized vehicles

There are different sized trucks and the side radars that detect parallel vehicles need
to take the own vehicle’s length into consideration. Long trailers might activate the
BSD in curves because the own trailer can be perceived as another vehicle.

• Non-highway roads
Non-highway roads such as city roads or smaller roads have tight turns. The LCP
should be deactivated during these conditions because the risk of false positive errors
is high.

• Road construction
During road work, tight curves and temporary line markings are used. This can in-
fluence the radars and cameras and false positive errors can activate different ADAS
functions, e.g. LCP and AEB.

• Tunnels
In tunnels, objects such as fans, low placed signs and walls can interfere with the radar
signals.

6.3.1 A Special Test Case

In the scenario presented in Figure 6.2, two vehicles are traveling in a three-lane highway
when both vehicles tries to change lanes to the same lane at the same time, causing an
accident.
In this case, depending on how the LCP is designed, the LCP might not get activated.
Both the BSD and the LKA have to be considered. The BSD might not activate in time
because the parallel distance between the vehicles is too large during the beginning of the
lane change. Furthermore, the LKA might not activate the counteracting steering torque
because the system might not know what to do when the vehicle is in the middle of two
lanes.
This is a case when the LCP might not work as intended, depending on the tuned
parameters. However all scenarios cannot be avoided and some errors will occur. E.g. if the
parallel distance parameter for BSD activation is increased, then in normal lane changes,
the BSD might start indicating too early due to other vehicles in the adjacent lane.

37
 Vehicle 2

Vehicle 1

Figure 6.2: Two vehicles are traveling in the same direction when both vehicles changes lanes
at the same time. Vehicle 1 is equipped with LCP.

6.4 Conclusion
Lane change prevention (LCP) is a relatively advanced ADAS function because it has a high
level of driving automation, combined with a high combined risk estimation presented in
section 4.1 and subsection 4.2.3. Therefore, extensive testing in enclosed areas is required
before testing on public roads.
Many ideas presented in the AEB testing can also be used when testing the LCP, such as
simulating sensor data and simulating other vehicles while driving. Simulating radar sensor
data is an important test method to use before using real vehicles because of the accident
risk. However, by simulating sensor data, only a part of the LCP is verified and therefore a
combination of both simulated and non-simulated test cases have to be performed.
A substitute to simulating vehicles is by using balloon vehicles. By using balloon vehicles,
full scale tests can be performed because the risk of damages is very low. Placing a balloon
vehicle in parallel and trying to perform a lane change manoeuvre verifies both the BSD and
the LKA, and therefore the whole LCP is verified.
The traffic environments are also important and have different roles. By testing in en-
closed areas, many different road environments cannot be tested due to limitations of the
test sites. Test sites that have different traffic environments exist, e.g. AstaZero. However,
public road testing also need to be performed because less common traffic environments can
and should be tested, such as sloped terrain, overhead signs, bridges and tunnels.
In the enclosed area testing, the full functionality of LCP can be tested and verified
compared to most public road test cases where only the BSD’s part of the LCP can be tested
and verified. Therefore, public road testing should be performed for test and verification of
the BSD because many different traffic situations and environments can be used, whereas in
the enclosed area testing the focus should be on the LKA’s part of LCP.

38
Chapter 7

Integration Testing of ADAS

7.1 Combined ADAS Functional Testing

When implementing new ADAS functions, it is not sufficient to only perform individual
functional testing because even if the individual function works as expected, the interaction
between already implemented and new ADAS functions might behave in an unexpected
manner. This section addresses this issue by providing an example of an unexpected behavior
during a traffic situation when both AEB and LCP are active.

2 Vehicle 2

1 Vehicle 1 Vehicle 3

Figure 7.1: Three vehicles traveling in the same direction, vehicle 1 is equipped with both
LCP and AEB. Vehicle 2 is positioned in the blind spot of vehicle 1.

The traffic scenario depicted in Figure 7.1 illustrates the need of combined ADAS func-
tional testing. In Figure 7.1, three vehicles are traveling in the same direction with the same
velocity when vehicle 3 suddenly brakes hard. The surprised driver in vehicle 1 might react
in two different ways, either by changing lanes if vehicle 2 is unobserved, or by braking hard.
If the driver in vehicle 1 tries to change lanes, the events in Table 7.1 might occur.

Event Action Consequence

1 Vehicle 3 brakes hard The AEB in vehicle 1 activates
2 Vehicle 1 starts the turn signal The AEB in vehicle 1 deactivates
3 Vehicle 1 starts to change lanes The LCP in vehicle 1 activates due to vehicle 2
4 Vehicle 1 is still in lane 1 Possible collision between vehicle 1 and 3
Table 7.1: Events and actions that might lead to an accident between vehicle 1 and 3
in Figure 7.1, when vehicle 1 tries to change lanes caused by vehicle 3’s hard braking.

39
 The traffic scenario in Figure 7.1 together with the events in Table 7.1 illustrate that even
if individual ADAS functions are working properly, the combination of functions might not
work as expected. This example was chosen to illustrate an issue and is not unique for these
functions. Therefore, this way of thinking has to adopted and combined ADAS functional
testing have to be performed when implementing new functions.

7.2 General Test Strategies

Investigated test methods from the two case studies AEB and LCP led to the conclusions
visible in Table 7.2. It presents the two main test methods; simulating sensor data and no
use of simulations, together with both methods’ advantages, disadvantages, complexity and
suitable test environments.

No simulations Simulating sensor data

Verifies: The whole function Algorithms and execution
Suitable environments: Enclosed areas, e.g. AstaZero Flexible
Complexity: Neutral Increases
Advantage: Verifies the whole function Safer, repeatable and faster
Disadvantage: Dangerous, time consuming Does not test the sensors
Table 7.2: Comparison between two test methods; simulating sensor data and no use of
simulations, used in the complete vehicle level testing.

The two test methods complement each other because simulating sensor data makes it
possible to perform fast repeatable tests, which is advantageous during early stages of the
development and when performing regression tests. Both the consumed time and the safety
are two aspects that are benefited when simulating. However, the whole function has to be
tested in a real vehicle at some point, which in turn decreases complexity and increases the
need of test environments with enough versatility and is the last step before market release.
Another general test strategy has been made and is presented in Figure 7.2. This test
strategy is a result of the combination of the comparison between the test methods in Ta-
ble 7.2 and the combined risk estimation in Figure 4.5.

40
Figure 7.2: This figure is a remodelled version of Figure 4.5, which has been divided into
four sections ranging from 1 to 4 and each number represents a combination of high/low
traffic safety risks and complexity.

The combined risk estimation in Figure 4.5 has been divided into four sections and is
visible in Figure 7.2. This has been performed in order to categorize the functions and
present a general test strategy for each section. Each section is characterized by its low/high
traffic safety risks and complexity values. Two type of aspects, environments and simulations
have been considered for the test strategies and the conclusion is visible in Table 7.3.

Section Suitable environments Simulations

1 Enclosed areas Minor simulations
2 Enclosed area, e.g. AstaZero High use of simulations
3 Public roads No simulations
4 All Minor simulations
Table 7.3: Environments and simulations to be used for each section in Figure 7.2.

It is hard to propose a general test strategy for each section because it depends on the
stage of the development. E.g. during early stages of the development, the simulation tool
PreScan could be used to test most functions from section 1-3 that can influence the vehicle’s

41
movement, and not for functions that only have detection/indication capabilities. Because
PreScan uses software models for vehicle dynamics, sensors and thereafter simulate together
with surroundings and traffic scenarios, only the ADAS algorithms are verified and not the
actual sensors. Furthermore, the full extent of the communication between the sensors and
the vehicle is not fully verified as it is tested in a simulating environment and not in real
hardware.
The proposed test strategies in Table 7.3 are therefore intended to be used when the
development has progressed and real vehicles can be equipped with the desired ADAS func-
tion. Functions in section 3 and 4 have a lower traffic safety risk and tests can be performed
on public roads, compared to functions with a higher traffic safety risk from section 1 and
2 that require enclosed area testing in order to avoid accidents. However, all functions in
section 4 can be performed in any environment because those functions cannot control the
vehicle’s movement. However, testing blind spot detection (BSD) and VRUD have to be
performed with great care and therefore enclosed area testing is recommended for initial
testing. Enclosed area testing is recommended because these functions have detection and
indication capabilities, therefore for the safety of surrounding vehicles and vulnerable roads
users, testing these functions can not be performed on unsuspecting persons.
Functions with low complexity, section 1 and 3, depend less on simulations because only
minor changes to already implemented functions are needed. But as the complexity increases,
simulations are necessary in order to perform fast repeatable testing and the possibility of
testing many different traffic scenarios and conditions. However, full simulations of complex
functions are very complex to perform and therefore simulating a part of the function or
vehicle is necessary. Complete vehicle testing by simulating sensor data should be used
because of the advantages and that it is widely used, as described in previous chapters.

42
7.3 Proposed Testing Methodology
A testing methodology that can be used for testing new ADAS functions is proposed in this
section. The methodology is based on different aspects that need to be considered when
setting-up test cases.

• Step 1, Define the purposes

Define which parts of the functions that need to be tested, together with defining in
which conditions the function is supposed to operate.

• Step 2, Consider affecting parameters

Define which parameters that can affect the testing. Aspects to consider are: influences
from other functions, road types, traffic environments, weather, location, the types of
sensors used and other road users.

• Step 3, Define important traffic scenarios

Depending on the function’s purpose, define specific traffic scenarios and situations
to consider when verifying the functionality. Both common and less common traffic
scenarios should be considered. Furthermore, scenarios that might induce false positive
errors should also be considered.

• Step 4, Set-up test cases and test environments

Define test cases that should be considered based on the aspects in step 1-3. The test
cases should be designed in such way to cover much of the function’s functionalities
by using few cases that are easy, fast and repeatable in order to simplify regression
testing. However, test cases containing less common traffic situations should also be
designed.
Test environments
Define where and how to perform the test cases. Consider if sensor simulation tools
should be used, or should no parts be simulated. Furthermore, define where to perform
the test cases, such as in enclosed areas or on public roads.

• Step 5, Evaluate the performed test cases

Define how to evaluate the results by comparing them with the specified requirements
to evaluate whether the test cases should be redesigned or not. E.g. if the test case
should be performed in enclosed areas instead of on public roads, or make the testing
more effective by simulating a part of the function.

43
7.3.1 The Testing Methodology Applied on Platooning
An example of how to use the testing methodology is presented for the platooning function.
Platooning has been chosen because it has a high combined risk estimation, 22.5 of 25, and
because it uses vehicle-to-vehicle and vehicle-to-infrastructure communication (V2X). The
presented test case can be both extended and limited to suit the tester’s preferences. In this
test case, platooning is assumed to be almost ready for market release and the interaction
between platooning and LCP is of interest. Two vehicles are traveling in a platoon in this
test case, when the lead vehicle begins a lane change maneuver due to an obstacle in the
current lane.
• Step 1, Define the purposes
The purposes are to verify the vehicle’s object detection system, lane change capabili-
ties and the lane change prevention (LCP) when two vehicles are traveling in a platoon
and the lead vehicle begins a lane change maneuver due to an obstacle in the current
lane.
• Step 2, Consider affecting parameters
Parameters that affect this test case: road curvature, weather conditions, type of
parallel vehicles and sensors. E.g. how far back and in parallel can the sensors detect
approaching vehicles and how accurately it can compensate for the road curvature.
• Step 3, Define important traffic scenarios
Two main traffic scenarios should be considered. Firstly the scenario when only the
object is presence and no other road users are nearby. Secondly, the scenario when
there are nearby vehicles in parallel which affects the lane change maneuver combined
with an object in the road.
• Step 4, Set-up test cases and test environments
This test case should be performed when no nearby road users are present.
– Step 1, Place an object or a standstill vehicle in one lane of a two lane road.
– Step 2, Drive a two-vehicle platoon on the same lane, towards the object.
– Step 3, The lead vehicle makes a lane change and the last vehicle should follow.
This test case should be performed when nearby road users are present.
– Step 1, Place an object or a standstill vehicle in one lane of a two lane road.
– Step 2, Drive a two-vehicle platoon on the same lane, towards the object.
– Step 3, Drive another vehicle in parallel with the last vehicle.
– Step 4, The lead vehicle begins a lane change.
The last test case tests what happens when one of the vehicles in the platoon cannot
perform a lane change. Step 3 can be altered by changing the other vehicles position
to be e.g. parallel with the lead vehicle or in parallel with both vehicles.

44
 Test environments
These test cases should be performed in an enclosed area by using real vehicles in the
platoon. However, the object and the parallel vehicle should be simulated. The parallel
vehicle can either be simulated by the last and/or by the leading vehicle.
• Step 5, Evaluate the performed test case
By simulating both the object and the parallel vehicle, safe, fast and repeatable tests
cases can be performed. Because the only risk of collision is between the two vehicles
in the platoon and in addition the test case can be set-up very fast and in different
locations within the enclosed area. Furthermore, by not placing real obstacles on the
test track, other test engineers can perform their own tests in parallel.

7.4 Future ADAS functions

The future types of ADAS functions refer to functions found in section 2.5 and are currently
under development at different vehicle companies. Most future functions are level 3 driving
automation functions described in section 4.1 and are therefore responsible for the safe
operation. Therefore, different aspects need to be considered compared to conventional
testing. Three aspects that should be further investigated are the following:

• The safety responsibility shifts from the driver to the system

As the level of driving automation increases, the safety responsibility shifts to the
system and other aspects have to be considered. E.g. if a sensor fault occurs, how
does the system handle this without causing accidents, or if an accident occur, how to
determine how and which vehicle caused the accident.
• Stepwise implementation and testing
As the functions become more complex, it is hard to develop the whole function without
continuous testing. Therefore, stepwise testing has to be performed, where parts of the
function is tested separately and thereafter tested together. Example of such function
is the LCP, where both BSD and LKA are tested separately and thereafter combined.
• Safety aspects
More complex and safety critical functions will have more control of the vehicle and
they will be able to control the full range of motion; therefore the tester’s safety aspects
have to be prioritized. How to ensure that the tester has full control of the vehicle
at all times, combined with if the tester knows which functions that are active during
different testing stages and different parts of the test scenario need to be considered.
This leads to using enclosed testing sites, such as the AstaZero, where different en-
vironments are available. Even if the test site is enclosed, the tester’s safety aspect
has to be considered because the vehicle might be able to perform more safety critical
maneuvers compared to conventional functions.

45
Chapter 8

Summary, Conclusion and Future

Work

8.1 Summary
In this report, current and future ADAS functions have been investigated with respect to
different types of functional classifications and test methods. Furthermore, a classification
based both on complexity and safety aspects have been performed. This lead to the case
study of lane change prevention (LCP), an ADAS function not yet released on the market.
The case study includes which aspects that need to be considered when testing LCP and
are based on the previous case study of autonomous emergency braking (AEB), an ADAS
function that has been widely tested at Scania and released to the market.
Furthermore, general test strategies for different types of ADAS functions based on the
classifications have been proposed. The test strategies present ideas of how to choose the dif-
ferent test set-ups and which aspects to consider. Finally, a testing methodology containing
five steps and aspects to consider when performing the tests have been presented, together
with an example.

8.2 Conclusion
As more ADAS functions are developed, new test methods have to be considered. Firstly,
future functions will be able to control the vehicle’s full range of motion, and secondly
the interaction between already existing ADAS functions and future functions have to be
considered. Even if individual ADAS functions work as intended, when equipping a vehicle
with multiple functions, unexpected behavior might occur as seen in section 7.1.
A single test strategy cannot be applied on all ADAS functions and therefore depending
on the function’s safety and complexity aspects, different test methods can be used. The
common aspect when testing ADAS functions is the possibility of using simulation software,
where sensor data can be simulated in real-time. This enables fast repeatable testing to be
performed as a single tester can simulate other vehicles compared to the conventional way
where multiple test engineers and vehicles have to be used.

46
 Furthermore, a testing methodology has been proposed in order to perform tests in a
systematic way. Other aspects to consider while performing tests is the tester’s safety because
the ADAS functions can control more parts of the vehicle and its movement compared to
conventional functions. Enclosed area testing, e.g. at AstaZero will have a greater role in
the future as testing more complex and larger traffic scenarios have to be performed, before
moving on to public road testing.
The test cases become more complex and the vehicles can control the full movement
are additional aspects to consider when evaluating the tester’s safety. Therefore, additional
factors will make it more complex to assess the tester’s safety in the future.

8.3 Future Work

A few aspects that should be considered for future work are:

• Data collection
Investigate how to collect data from future tests, such as information about the sur-
roundings, sensor data and the used traffic scenario. This has to be recorded in some
way and thereafter synchronized with the sensor data in order to get an overview of
what occurred during the test and during which circumstances the function activated.

• Dynamical test scripts

To further improve the sensor data simulation tool, dynamical test scripts have to be
developed. The purpose is to enable multiple vehicles to be simulated at the same
time and also introduce the possibility of adding and removing simulated vehicles and
change their properties in real-time when performing tests.

• Synchronizing sensors while simulating

If several sensors are simulated at the same time, they have to be synchronized so that
all the sensors’ data correspond with each other. E.g. if a vehicle is simulated, and
the simulated sensors are not completely synchronized because of a small lag, then the
simulated vehicle’s position will not be the same for all the sensors and therefore the
test case will not be performed correctly.

• Safety
If the function can control the vehicle’s full range of motion, safety aspects have to
be considered to ensure the tester’s safety. Different aspects should be considered,
e.g. how to conduct the test, whether the test engineer should be inside the vehicle
or control it remotely. Introducing a kill switch to disable all the functions in case of
emergency should also be considered.

47
Bibliography

Kareem Abdelgawad, Bassem Hassan, Michael Grafe, and Iris Gräßler, editors. A Scalable
Framework for Advanced Driver Assistance Systems Simulation, 6th International Con-
ference on Advances in System Simulation (SIMUL 2014), October 2014. IARIA. In the
proceedings of SIMUL 2014, the sixth International Conference on Advances in System
Simulation, Nizza, Frankreich, 12. Okt. - 16. Okt. 2014, IARIA.

Mikael Adenmark. Embedded systems test levels. Private communications, 2015. Creation
Date: 2013-11-19.

AstaZero. About astazero. http://www.astazero.com/the-test-site/about/, 2015. Ac-

cessed: 2015-04-08.

Audi. Long-distance test drive successfully completed: Audi a7 sportback pi-

loted driving concept arrives in las vegas following 560 mile drive, 2015.
URL http://www.audiusa.com/newsroom/news/press-releases/2015/01/
550-mile-piloted-drive-from-silicon-valley-to-las-vegas.

Euro NCAP. About aeb. http://www.euroncap.com/en/vehicle-safety/

the-rewards-explained/autonomous-emergency-braking/, 2015a. Accessed: 2015-04-
11.

Euro NCAP. Assessment protocol – safety assist. http://euroncap.blob.core.

windows.net/media/1572/euro-ncap-assessment-protocol-sa-v60.pdf, 2015b. Ac-
cessed: 2015-05-26.

Euro NCAP. About ldw. http://www.euroncap.com/en/vehicle-safety/

the-rewards-explained/lane-support/, 2015c. Accessed: 2015-04-11.

G Geiser. Man machine interaction in vehicles. ATZ, 87:74–77, 1985.

Olaf Gietelink, Jeroen Ploeg, BD Schutter, and Michel Verhaegen. Testing advanced driver
assistance systems for fault management with the vehil test facility. In Proceedings of the
7th International Symposium on advanced vehicle control, pages 579–584, 2004.

Olaf Jeroen Gietelink. Design and validation of advanced driver assistance systems. TU
Delft, Delft University of Technology, 2007.

48
Global NCAP. Active blind spot assist. http://www.globalncap.org/about/, 2015. Ac-
cessed: 2015-05-25.

John Golias, George Yannis, and Constantinos Antoniou. Classification of driver-assistance

systems according to their impact on road safety and traffic efficiency. A Transna-
tional Transdisciplinary Journal, 22(2):179–196, 2002. ISSN 0144-1647. doi: 10.1080/
01441640110091215.

Google, Inc. Google self-driving car project monthly report, 2015. URL http:
//static.googleusercontent.com/media/www.google.com/sv//selfdrivingcar/
files/reports/report-0815.pdf.

Mohd Ehmer Khan, Farmeena Khan, et al. A comparative study of white box, black box
and grey box testing techniques. International Journal of Advanced Computer Science
and Applications (IJACSA), 3(6), 2012.

Andreas Knapp, Markus Neumann, Martin Brockmann, Rainer Walz, and T Winkle. Code of
practice for the design and evaluation of adas. Preventive and Active Safety Applications,
eSafety for road and air transport, European Commission Project, Brüssel, 2009.

Mercedes-Benz. Active blind spot assist. http://techcenter.mercedes-benz.com/en/

active_blind_spot_assist/detail.html, 2015. Accessed: 2015-04-22.

NHTSA. Preliminary statement of policy concerning automated vehicles. Technical report,

National Highway Traffic Safety Administration, 2012.

SAE Standard J3016. Sae international taxonomy and definitions for terms related to on-road
motor vehicle automated driving systems, ”levels of driving automation”, 2014.

TASS International. Prescan - simulation of adas & active safety, 2015. URL https:
//www.tassinternational.com/prescan. Accessed: 2015-07-29.

The European Commission. REGULATION (EC) No 661/2009 OF THE EUROPEAN

PARLIAMENT AND OF THE COUNCIL. The European Commission, 2009. URL http:
//eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009R0661.

The European Commission. Road Safety Programme 2011-2020: detailed measures.

The European Commission, 2010. URL http://europa.eu/rapid/press-release_
MEMO-10-343_en.htm?locale=en.

The European Commission. Cooperative Intelligent Transport Systems and Services.

The European Commission, 2013. URL https://eu-smartcities.eu/sites/all/
files/Cooperative%20Intelligent%20Transport%20Systems%20and%20Services%
20-%20Smart%20Cities%20Stakeholder%20Platform%20january.pdf.

The European Commission. Rolling Plan on ICT Standardisation. The European Commis-
sion, 2015. URL http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=9137.

49
Mihiar Ayoubi Tom M. Gasser, Clemens Arzt et al. Legal consequences of an increase in
vehicle automation: Consolidated final report of the project group. Technical report,
Bundesanstalt für Straßenwesen, 2012.

U.S. Department of Transportation National Highway Traffic Safety Administration. Na-

tional Motor Vehicle Crash Causation Survey: Report to Congress (DOT HS 811 059).
CreateSpace Independent Publishing Platform, September 2013. ISBN 1492772607.

World Health Organization. Violence and Injury Prevention and World Health Organization.
Global Status Report on Road Safety 2013: Supporting a Decade of Action. World Health
Organization, 2013. ISBN 9789241564564. URL http://books.google.se/books?id=
79eNmwEACAAJ.

50
TRITA XR-EE-RT 2015:014
ISSN 1653-5146

www.kth.se