Czech Technical University in Prague

Faculty of Mechanical Engineering

Department of Automotive, Combustion Engine and Railway Engineering

Study program: Master of Automotive Engineering
Field of study: Advanced Powertrains

Simulation of AEB system testing

DIPLOMA THESIS

Author: Bc. Patrik Zíta

Supervisor: Ing. Václav Jirovský, Ph.D.
Year: 2017
Před svázáním místo téhle stránky vložíte zadání práce s podpisem děkana.
Disclaimer

I hereby declare that this thesis is my own work and that, to the best of my
knowledge and belief, it contains no material which has been accepted or
submitted for the award of any other degree or diploma. I also declare that all the
software used to solve this thesis is legal.
I also declare that, to the best of my knowledge and belief, this thesis contains
no material previously published or written by any other person except where due
reference is made in the text of the thesis.

........................... ........................................
date Bc. Patrik Zíta
 Acknowledgment

I would like to thank my supervisor Ing. Václav Jirovský, Ph.D. for his guidance
and support throughout this thesis. I would like also to thank TÜV SÜD Czech s.r.o.
for support and experience which I got during five months’ internship. Lastly, I
would like to thank my whole family for their support and help during a difficult
period of last months.

Bc. Patrik Zíta

Title:
Simulation of AEB system testing

Author: Bc. Patrik Zíta

Study program: Master of Automotive Engineering

Field of study: Advanced Powertrains
Assignment: Diploma Thesis

Supervisor: Ing. Václav Jirovský, Ph.D.

Department of Automotive, Combustion Engine and Railway
Engineering, Faculty of Mechanical Engineering, Czech Technical
University in Prague

Abstract: This master thesis describes a simulation tool which was created
to analyze ADAS functions and vehicle dynamics. The tool was
created in CarMaker and Microsoft Excel. The software can be
used as SIL testing to analyze sensor output data before proving
ground test.

Key words: CarMaker, ADAS, autonomous vehicle, AEB, simulation,

testing
Contents

List of Figures ........................................................................................ 9

Abbreviations ...................................................................................... 11

Introduction ........................................................................................ 12

1. Advanced Driver Assistance Systems ............................................... 13

1.1. General description .........................................................................................13
1.2. Systems and its principles ..............................................................................14
1.2.1. Adaptive Cruise Control .......................................................................14
1.2.2. Automatic Emergency Brake ..............................................................15
1.2.3. Blind Spot Detection System (BSD) ....................................................16
1.2.4. Emergency Brake Assist ......................................................................17
1.2.5. Lane Departure Warning, Lane Keeping Assistant ..........................18
1.2.6. Traffic Sign Recognition.......................................................................19
1.3. Vehicle sensors [6] ...........................................................................................21
1.3.1. RaDAR (Radio Detection and Ranging) ............................................21
1.3.2. LiDAR (Light Detection and Ranging) ..............................................23
1.3.3. Optical cameras ....................................................................................23
1.3.4. PMD (Photonic Mixer Device) sensors ..............................................24
1.3.5. Ultrasonic sensors ................................................................................24
1.3.6. Information evaluation ........................................................................25
1.4. Sensor physics modeling ................................................................................26
1.4.1. Sensor modeling complexity...............................................................30
1.4.2. Advanced RaDAR sensor modeling ..................................................30
1.4.3. Modeling of a new generic virtual optical sensor for ADAS
prototyping ...........................................................................................31

2. Software.......................................................................................... 32

3. Simulation of predefined driving scenarios ...................................... 38

3.1. Test track description ......................................................................................38

7
 3.2. Maneuver description .....................................................................................40
3.3. Vehicle description ..........................................................................................41
3.4. Description of driving scenarios ....................................................................46
3.5. Parametrization of driving scenarios ............................................................51
3.6. Evaluation of driving scenarios .....................................................................59
3.7. GPS coordinates as results of simulations ...................................................72

4. Conclusion ...................................................................................... 73
4.1. Contributions....................................................................................................73
4.2. Assignment .......................................................................................................73
4.3. Future work ......................................................................................................73

List of sources ..................................................................................... 74

CD content .......................................................................................... 77

8
 List of Figures

Figure 1.1 - Adaptive Cruise Control [17] ..................................................................................... 15

Figure 1.2 - AEB functionality [22] ................................................................................................. 16
Figure 1.3 - Blind spot detection [41][42] ....................................................................................... 17
Figure 1.4 - Sequence of used system for critical braking ........................................................... 17
Figure 1.5 - Citroën LDW system ................................................................................................... 18
Figure 1.6 - Lane Keeping Assistant............................................................................................... 19
Figure 1.7 - Traffic sign recognition [2] .......................................................................................... 20
Figure 1.8 - Sensors in vehicles [7].................................................................................................. 21
Figure 1.9 - RaDAR sensors application [23] ................................................................................ 22
Figure 1.10 - Type of RaDAR on vehicles [11] .............................................................................. 22
Figure 1.11 - LiDAR produced by Continental [12] ..................................................................... 23
Figure 1.12 - Stereo Camera [19] ..................................................................................................... 24
Figure 1.13 - Ultrasonic sensor for parking [20] ........................................................................... 25
Figure 1.14 - Overview of the sensing process [25]...................................................................... 26
Figure 1.15 - AEB braking and graph representing acceleration and pitch [27] ...................... 29
Figure 1.16 - Sensors in CarMaker [26] .......................................................................................... 30
Figure 2.1 - CarMaker - virtual testing software [21] .................................................................. 32
Figure 2.2 - CarMaker ...................................................................................................................... 33
Figure 2.3 - CarMaker - car setup ................................................................................................... 34
Figure 2.4 - CarMaker - road setup ................................................................................................ 35
Figure 2.5 - Export of GNSS data from CarMaker to Microsoft Excel ...................................... 35
Figure 2.6 - dSpace - Automotive Simulation Models [33] ......................................................... 36
Figure 2.7 – CarSim [35] ................................................................................................................... 37
Figure 3.1 - CarMaker and GPS ...................................................................................................... 39
Figure 3.2 – Test track Hradčany u Mimoně in CarMaker ......................................................... 39
Figure 3.3 - Google Earth view from CarMaker ........................................................................... 40
Figure 3.4 - Maneuver dialog .......................................................................................................... 41
Figure 3.5 - VW Beetle sensor setup ............................................................................................... 42
Figure 3.6 - VW Beetle vehicle control ........................................................................................... 43
Figure 3.7 - Closed loop of the ACC-Controller ........................................................................... 43
Figure 3.8 - BMW 5-series sensor setup ......................................................................................... 44
Figure 3.9 - BMW 5-series vehicle control ..................................................................................... 45
Figure 3.10 - T02 - CTU 02/2013 C ................................................................................................. 46
Figure 3.11 - T02 - CTU 02/2013 B ................................................................................................. 46
Figure 3.12 - T05 - CTU 02/2013 E ................................................................................................. 47
Figure 3.13 - T06 - CTU 02/2013 F.................................................................................................. 47
Figure 3.14 - T07 - CTU 02/2013 G ................................................................................................. 48
Figure 3.15 - T08 - ES 347/2012 A................................................................................................... 48
Figure 3.16 - T 12 - ISO 15623 B....................................................................................................... 49
Figure 3.17 - T15 - ISO 22178 B........................................................................................................ 49
Figure 3.18 - T16 - ISO 22178 C ....................................................................................................... 50
9
Figure 3.19 - T18 - ISO 22179 A ....................................................................................................... 50
Figure 3.20 - T19 - ISO 22179 B........................................................................................................ 51
Figure 3.21 - Clear view (A) and description window (B) of the Test Manager GUI ............. 52
Figure 3.22 – eGo and SCT driving parameters – Case B............................................................ 59
Figure 3.23 - eGo driving parameters for ACC - Case B ............................................................. 60
Figure 3.24 - Speeds of each vehicle during simulation - Case B ............................................... 61
Figure 3.25 – ACC parameters setup ............................................................................................. 62
Figure 3.26 – ACC behavior of eGo vehicle – Case B .................................................................. 63
Figure 3.27 – ACC parameters tuning ........................................................................................... 63
Figure 3.28 -FCW and AEB control factors - Case B .................................................................... 64
Figure 3.29 – eGo behavior during target’ braking – Case B ...................................................... 66
Figure 3.30 - eGo and target behavior during maneuver - Case B ............................................ 67
Figure 3.31 – eGo detecting new target and set desired distance – Case B .............................. 69
Figure 3.32 – eGo reaction to decelerating target – Case B ......................................................... 70
Figure 3.33 -eGo and parallel vehicle speed profile – Case B ..................................................... 71

10
Abbreviations

ABS Anti-Lock Braking System

ACC Adaptive Cruise Control
ADAS Advanced Driver Assistance Systems
BSD Blind Spot Detection
CMS Collision Mitigation System
EBA Emergency Brake Assist
ESC Electronic Stability Control
ESP Electronic Stability Program
GNSS Global Navigation Satellite System
GPS Global Positioning System
LCDAS Lane Change Decision Aid Systems
LDW Lane Departure Warning
LKS Lane Keeping System
SCT Soft Crash Target
TSR Traffic Sign Recognition

11
Introduction

During 20th-century vehicles improved people ‘s lives in a way of faster transport

for longer distances. Now, vehicles have become an essential part of everyday life.
On one hand, they enhance people’s comfort but at the same time can endanger their
lives. With the increase in traffic density, the number of interactions between all
elements of the transport system increases too and that means a higher probability of
crisis situations or even traffic accidents. There is an effort to reduce the number of
these situations or at least limit its effects.
Automotive companies are continuously improving vehicle safety for past few
decades. The safety systems developed in vehicles can be divided into two categories:
passive safety and active safety. Passive safety reduces the injuries sustained by
passengers when an accident occurs. For example, airbags and seatbelts. Active safety
systems are systems that try to avoid accidents in general. For example, ABS can
prevent wheels from locking up when driver brakes and he can continue to steer.
Advanced Driving Assistance System (ADAS) can alert the driver to potential
problems or avoid collisions by implementing safeguards and taking over the control
of the vehicle [7].
It is expected that active safety systems will play a key role in collision avoidance
in the future. Each application supported by ADAS requires its private sensor(s), so
adding new applications will require more sensors. Different sensors have different
observation capabilities and various detection properties. These systems are tested
during development but it is also necessary to evaluate their proper function and
activation during a real drive.
This master thesis describes the development of real-time simulations which were
created to evaluate vehicle behavior under different conditions with regards to ADAS
systems and vehicle dynamics. Those systems are continuously developing and to
save time and money it is very useful to simulate as much as we can. Some of the
testing scenarios are not possible to realize because of its danger or its complexity.
Proper testing of safety systems is necessary to avoid unwanted activation e.g.
AEB during rapid changing lane on the highway. The main motivation was to create
simulations with same scenario but different conditions and evaluate the effect of
each variable. These simulations can be used to improve sensors and software in
vehicles to increase reliability.
The goal of diploma thesis is to realize simulation testing loop to test ADAS/AEB
systems primarily with software simulation tools and optimized output for
hardware-in-the-loop validation. Another part is research of state-of-the-art in the
field of ADAS system software testing with regards to sensor physics modeling and
sensor description in general. In the end output of this simulation should be geodetic
coordinates and speeds for final test procedure validation in proving ground tests.
Autonomous systems are not easy to develop and implement in real life, as there
are many interactions with surroundings which must be correctly understood by
sensors and software to provide the correct response.

12
 Chapter 1

1. Advanced Driver Assistance

Systems

1.1. General description

Common systems like ABS, ACC, ESP and much more are used in nowadays
cars. Car producers and its suppliers want to increase safety, so inevitably it has
led to the production more sophisticated vehicles. Cars also became a part of our
everyday life, that means it is usual to have more than one car per family. This
has led to an increasing number of inexperienced drivers who can easily cause
an accident. The second class of dangerous drivers are those who drive thousands
of kilometers per month and are distracted by their work or other activities whilst
driving, and therefore do not fully focus on the road while driving. For these and
other reasons, many automotive companies are developing Advanced Driver
Assistance Systems (ADAS).
Advanced Driver Assistance Systems are electronic systems that are designed
to support the driver in his driving. This support is ranging from simple
information presentation through advanced assisting and even taking over the
driver’s tasks in a critical situation. The common characteristic of these ADAS is
that they (compared to passive safety systems) directly intervene with the driving
task leaving it a delicate task for the automotive industry to integrate these
systems in their vehicles, get the drivers to accept them and most importantly,
having them improve traffic safety in the way they are intended to.
On the other hand, for many experienced drivers, some of those systems are
unnecessary and they perceive them as an irritation, especially when those
systems cannot be switched off.
For many automotive companies, ADAS is a tool to reduce accidents to zero
and ultimately to achieve produce fully autonomous vehicles. Nevertheless,
there is still a long way to go and many problems must be solved before such cars
can go on roads autonomously.

13
1.2. Systems and its principles
Many companies across the world are developing ADAS systems in the
automotive industry. The main players are Bosch Group, Delphi Automotive
Company, Valeo SA, Continental AG, Panasonic Corporation, TRW Automotive,
Denso Corporation etc. [3]. Those companies are developing similar systems, but
sometimes with different names.
In general, the ADAS systems can be divided into several various categories:
lateral control, longitudinal control & avoidance, parking aids and so on [36].

Examples of systems which are considered as ADAS are:

• Adaptive Cruise Control

• Automatic Emergency Brake

• Blind Spot Detection

• Emergency Brake Assist

• Lane Change Assistant

• Lane Departure Warning

• Traffic Sign Recognition

1.2.1. Adaptive Cruise Control

Adaptive Cruise Control (ACC) is a system which automatically adjusts the

vehicle speed to maintain a safe distance from vehicles ahead without using the
throttle or brake pedals. It helps to decrease fuel consumption and keep traffic
flowing.
The first kind of this system was introduced in 1995, but the functionality was
limited to use only throttle control or down-shifting to adjust the speed. In 1999
Mercedes introduced ACC Distronic which was the first RaDAR-assisted ACC
and it could apply brakes [16]. The first manufacturer to offer ACC capable of a
complete stop and go was BMW with their 7 series. Not only premium brands
like BMW and Mercedes were developing these systems also Volkswagen Group,
GM or PSA Group did.
Very first version of ACC was based on laser, but due to the environmental
conditions like weather reliability was affected. Nowadays system using long-
range RaDARs (full range). Typical long-range RaDAR specification is that it sees
up to 200 m which are equivalent to about six seconds of lead time at highway
speeds but in a small range around 15 – 20°. This system also uses short range
RaDAR for closer distances about 30 m or one second of lead time and the range
is around 80° [37]. This type of RaDAR works in a wider range of environmental
conditions and does not have a problem with recognizing non-reflective cars.
14
 Figure 1.1 - Adaptive Cruise Control [17]

1.2.2. Automatic Emergency Brake

Automatic Emergency Brake (AEB) systems improve safety in two ways:

firstly, they help to avoid accidents by identifying critical situations early and
warning the driver; and secondly, they reduce the severity of crashes which
cannot be avoided by lowering the speed of collision and, in some cases, by
preparing the vehicle and restraint systems for impact [1][14].
This system can apply braking power automatically without driver
intervention. AEB continuously monitors the area in front of the car and when
the systems recognize a serious possibility of a collision occurring then the driver
is alerted to start braking and brakes are pre-activated. Sometimes small braking
power is applied to save as much braking distance as possible. If the driver, at
the critical distance, does not start braking, the system automatically applies as
much braking power as possible to stop the vehicle or to reduce speed and the
possibility of a fatal accident. An example of an AEB system at work is shown in
figure 1.2.
Rear-end collisions mostly occur in inter-urban areas and at speeds of up to
25 km/h. To monitor the rear-end of a car, manufacturers use RaDAR, (stereo)
camera and/or LiDAR-based technology to identify potential collision partners
ahead of the car. Short Range LiDAR is cheaper, works at speeds of up to 50 km/h
and is used in the compact car segment because it became an active safety
standard, along with ABS and ESC.
Long Range RaDAR Sensor is necessary for adaptive cruise control as it can
also recognize critical situations and work at speeds of up to 200 km/h [8].

15
 Figure 1.2 - AEB functionality [22]

1.2.3. Blind Spot Detection System (BSD)

The blind spot is a space where the driver is unable to see. In urban traffic,
critical situations may arise if vehicles in the so called blind spots are overlooked.
Blind spots can be either on the side or behind the vehicle and through a camera
integrated into the lateral rear window, the blind spot detection system provides
the driver with information on whether there are any vehicles, cyclists or
pedestrians in the area not visible to him.
These spots are dangerous because pedestrians or even vehicles can be
missed. The blind spot is also defined by ISO 17387:2008. This norm describes
Lane Change Decision Aid Systems (LCDAS) — Performance requirements and
test procedures and the location and size of the spots.
BSD systems use a combination of sensors/cameras to recognize objects and
provide information about an object to the driver. This information is often
provided through an orange lamp in the mirror and is generated depending on
the difference in speed between the driver’s own vehicle and others but some
automotive companies also prefer vibration of the steering wheel or a
combination of these with sound.
The latest versions of BSD systems can recognize the difference between large
or small objects and warn the driver that a car, pedestrian or motorcycle is in a
blind spot [4] [10]. Figure 1.3 shows an example of warning on the right side of
the figure and monitoring area on the left side.

16
 Figure 1.3 - Blind spot detection [41][42]

1.2.4. Emergency Brake Assist

Emergency Brake Assist (EBA) detects danger and distributes optimum
braking pressure to each wheel to ensure as short a braking distance as possible.
Research conducted in 1992 at the Mercedes-Benz driving simulator in Berlin
revealed that more than 90% of drivers fail to brake with enough force when
faced with an emergency. By interpreting the speed and force with which the
brake pedal is pushed, the system detects if the driver is trying to execute an
emergency stop, and if the brake pedal is not fully applied, the system overrides
and fully applies the brakes until the Anti-Lock Braking System (ABS) takes over
to stop the wheels locking up. Each car manufacturer has its own emergency
braking system technology, but they all rely on some type of sensor input. Mostly
speed with which a brake pedal is depressed.
EBA system is often combined with other brake systems like AEB, ESP and
ABS. AEB systems use lasers, RaDARs or even video data [1]. This sensor input
is then used to determine if there are any objects present in the path of the vehicle.
If an object is detected, the system can then determine if the speed of the vehicle
is greater than the speed of the object in front of it. A significant speed differential
may indicate that a collision is likely to occur, in which case the system is capable
of automatically activating the brakes. If driver does not act EBA pump up brake
system and apply full brakes. Slippery road can cause sideways sliding, so ESP
is activated and if wheels are block ABS prevent it. Entire process is described in
figure 1.4.

AEB EBA ESP ABS

Figure 1.4 - Sequence of used system for critical braking

17
 1.2.5. Lane Departure Warning, Lane Keeping
Assistant

These kinds of systems are designed to reduce collisions especially on

highways and to eliminate run-off-lane accidents. Lane Departure Warning
(LDW) and Lane Keeping Assistant (LKAS) are systems which use optical
recognition of markers on roads, usually white lines. They rely mainly on optical
recognition, so those systems are sensitive to the quality of roads markings and
the effects of the weather. That means that there is a high possibility of a mistake
in heavy rain, snow or if there is excessive glare from the sun.
LDW is a simple system which will only warn the driver when to start
moving out of the lane. This system cannot steer the wheels [5].
LKAS is more proactive. This system also monitors lane markings, but it can
take corrective action and return vehicle between lanes. If the driver doesn’t
respond to an initial warning, a Lane Keeping Assistant can typically act to keep
the vehicle from leaving its lane.
Early Lane Departure Warning systems used single video camera to monitor
lane markings, but modern systems use multiple cameras placed on bumper or
wind shield. Citroën became the first in Europe to offer LDW system on its 2005
C4 and C5 models, and its C6 [31]. It works with six cameras altogether mounted
at the bottom of the front bumper. This system is presented in figure 1.5.

Figure 1.5 - Citroën LDW system

18
 Figure 1.6 - Lane Keeping Assistant

1.2.6. Traffic Sign Recognition

Traffic Signs Recognition (TSR) is a system which helps drivers to watch

traffic signs. The vehicle can recognize the traffic signs and display an icon on the
dashboard or a head-up display. An example is shown in figure 1.7. This system
uses video cameras and video analysis to recognize signs and compare it with
the digital maps data which it receives from GNSS navigation or traffic services.
The process of sign recognition is divided into two phases. The first step is
the traffic signs detection in a video or image by using image processing. The
second part is the identification of the detected signs. This system has one
disadvantage. When traffic signs valid only for limited distance and they do not
have end signs to which could be recognized by the system. E.g. reduction of a
speed limit before crossroads is made by signs. In most cases, the end of speed
restriction is done by end of crossroads, not by end sign. In such case, the system
cannot recognize change and if there is no connection to digitalize maps data or
data are old, then the system will show wrong signs [2].
TSR not only reduces the prosecution risk but encourages maintaining a legal
speed, obeying traffic instructions and safe driving as well. Using vision
information only, a TSR systems can recognize and interpret both fixed traffic
signs and variable LED signs. However, the signs covered by trees, vehicles or
any other obstacle might not be detected by the system.

19
Figure 1.7 - Traffic sign recognition [2]

20
1.3. Vehicle sensors [6]
Current vehicles are equipped with many sensors for different purposes. ADAS
systems need sensors to provide all necessary data from surroundings. These can
monitor driver, car, and environment. Figure 1.8 shows typical sensors used in a
modern vehicle.

Figure 1.8 - Sensors in vehicles [7]

1.3.1. RaDAR (Radio Detection and Ranging)

RaDAR sensors usually work on frequencies 24 or 76-81 GHz. The 24GHz systems
are being used for short- and mid-range smart-driving features such as blind-spot
detection and collision avoidance in a wider area. Ranges of those sensors are around
50 – 60 m with a beam angle of 90 degrees. The 24GHz frequency band has a few
limitations. These include the potential for interference with radio astronomy and
satellite services and, as a result, these RaDARs will be phased out of new vehicles by
2022 in Europe [24]. Types of RaDARs are shown in figure 1.10.
RaDARs with frequencies around 77 GHz are used to detect obstacles in a long
range around 100 - 200 m and a beam angle of 15 - 20 degrees as it is shown in figure
1.9. The technical advantages of the 77GHz band include that the higher frequency
pairs effectively with a smaller antenna. The relationship between the antenna size
and the frequency is linear, so 77GHz systems will need antenna sizes a third of the
size of the current 24 GHz ones. The most important thing is that the wider bandwidth
available in the 77 GHz band enables greater accuracy and, as a result, provide drivers
with better object resolution [32].

21
 Figure 1.9 - RaDAR sensors application [23]

All automotive RaDARs are Doppler type [37]. The signal from the RaDAR is
transmitted and received continuously and modulated to recognize stationary
obstacles. RaDAR sensors for ACC or AEB usually contain two transmitters and four
receivers or one transmitter and two receivers as a cheaper option which is used for
detection of rear vehicles [11].

Figure 1.10 - Type of RaDAR on vehicles [11]

22
 1.3.2. LiDAR (Light Detection and Ranging)

LiDAR is a RaDAR which uses ultraviolet or near infrared light to image objects.
Typical automotive LiDARs have wavelengths around 850 or 900 nm. Usually, they
are pulsed with power around tens of milliwatts with peak power of pulse up to 80
W. The range of common LiDARs is from 10 to 20 m and they are used to detect
obstacles in low speed during urban driving. LiDARs were first applied as sensors
for ACC because they were smaller. Nowadays they are often replaced by RaDARs
or cameras due to excessive cost and low-resolution capabilities [6], [18]. Typical
LiDAR is shown in figure 1.11.

Figure 1.11 - LiDAR produced by Continental [12]

1.3.3. Optical cameras

Cameras such as mono, surround view, rear view or stereoscopic presented in

figure 1.12 are also used in vehicles. Car manufacturers use two types of cameras, one
which works in a visible spectrum of the light (380 - 780 nm) or the other that works
near the infra-red spectrum of the light (760 - 1400 nm) [37]. The range of those
cameras depends on their resolutions and frame frequencies. They focus on using
black and white images with low resolution to decrease computing time as much as
possible. Hence cameras for pedestrian recognition need resolution around 360 x 240
pixels and frame rate of 10 Hz. The best parameters have cameras which are used for
traffic sign recognition and LKAS as they have resolution 752 x 480 pixels and frame
rate of 15 Hz. The newest stereoscopic cameras can have a resolution up to 1280 x 980
pixels. Cameras are sensitive to harsh weather conditions so they are often used as
support for RaDAR systems.
Another usage of cameras is for driver monitoring. These cameras monitor the
speed of eyes winking and head movements. From such information system can
recognize that driver does not pay full attention and should take a rest.

23
 Figure 1.12 - Stereo Camera [19]

1.3.4. PMD (Photonic Mixer Device) sensors

They are sensors with short and middle range. The principle is that they shoot
infra-red spectrum of light (740 - 870 nm) from reflected object in the range of
sensors and measure duration of light beam flight. It is very like LiDARs but
PMD sensors use CCD or CMOS to shoot a whole picture. The advantage of those
sensors is a detection of the scene in 3D directly and a precise image compares to
stereoscopic cameras. These sensors are used by Lexus in their luxurious models.

1.3.5. Ultrasonic sensors

Ultrasonic sensors are used for low speed, especially for parking and
maneuvering like in figure 1.13. The range of such sensors is from 3 to 10 m and
their precision is around 5 cm. Sensors units which are also transmitters and
receivers send cone signal 40 times per second with frequency from 30 to 40 kHz
and beam angle 30 - 45 degrees. Although ultrasonic sensors are mainly used for
parking, some car manufacturers manage to extend their usage by integrating
them into safety systems. The problems are that wide signal cone is difficult to
direct and it leads to the discrediting of the result, so it is not feasible to create a
correct analysis of the surrounding in brief time. One of the application is blind
spot detection to recognize other cars around the vehicle.

24
 Figure 1.13 - Ultrasonic sensor for parking [20]

1.3.6. Information evaluation

Camera, LiDAR or RaDAR, just each system which acquires images, must be
able to acquire and analyze this image correctly. For those analyses, there are
used two methods which can be used simultaneously.
The first method is known as pattern recognition which means that it is based
on recognition of known shapes or patterns, these patterns are saved in the
database.
The second method works on the principle of comparing two or more
consecutive images and finding changes of points and for these points determine
their positions and direction of movement.
The first method does evaluate object which is not in a library as unknown,
the second one does not have to know any object and it evaluates only the
possibility of occurrence of moving points in a trajectory of the car, so it can detect
some points as dangerous but, it would be only some inappropriate group of
points which are not dangerous. Static objects are analyzed as objects with speed
of the car and can be also detected by this method.
These sensors often cooperate or use data from other basic sensors inside
vehicles to ensure safety and proper run. Nowadays a lot of effort is put into
Vehicle2Vehicle (V2V), Vehicle2Infrastructure(V2I) or generally
Vehicle2Everything (V2X) communication.

25
1.4. Sensor physics modeling
The degree of automation in the car in the form of advanced driver assistance
systems is steadily on the rise. This means the development of more complex
systems and requirements for quick feedback on viability and robustness [25]. A
significant help with these problematics can be provided by a virtual
environment. Virtualization alleviates the dependency on hardware availability
and provides a controlled environment with reproducible conditions. To fulfill
this role, a sensor model must generate the sensor data that constitutes the input
of the function algorithms in such a way as to be virtually indistinguishable from
a comparable real-world scenario.

Figure 1.14 - Overview of the sensing process [25]

(a) Detection and processing chain of a real sensor.

(b) Direct mapping of virtual objects in the simulated environment onto an
output object list.
(c) Separate models for the measurement and processing steps connected by a
raw data interface.
(d) Sensor raw data generated by a measurement model used as stimulation for
the signal processing on the sensor ECU in a hardware-in-the-loop setup.

In a real environment, sensor maps its targets (e.g. other cars, static obstacles)
onto a digital representation. Then compare it with object list (pattern
recognition) or comparing two or more consecutive images and finding changes
of points. The sensing process consists of two subsequent steps: measurement
and processing. Measurement is the detection of sensor targets by means of an
electromagnetic (RaDAR, LiDAR, camera) or acoustic (ultrasound) interaction.
From the resulting raw data, a signal processing unit extracts objects and object
properties. An example is in Figure 1.14 – (a).
26
 In a virtual environment, the input consists of virtual objects provided by a
simulation framework. Direct mapping encompassing both the measurement
and processing steps is usually achieved by means of a stochastic model – Figure
1.14 – (b).
An independent treatment of effects occurring during the two steps comes at
the cost of increased complexity and requires a raw data interface – Figure 1.14 –
(c).
This opens the possibility of a hardware-in-the-loop setup with the electronic
control unit (ECU) of the sensor stimulated by simulated raw data – Figure 1.14
– (d).

properties of sensor targets properties of detected objects

unique object ID tracking ID
existence probability
object type (e.g. vehicle, pedestrian) classification vector
object class (e.g. sedan, child)
position, velocity, acceleration vectors position, velocity, acceleration vectors
with measurement uncertainties
point of reference for the position
measurement (usually a corner of the
orientation and rotational rate (yaw, bounding box)
orientation and rotational rate with
pitch, roll angles and rates) measurement uncertainties
length, width, height of bounding box bounding box with size uncertainties
(surface) material properties reflectivity measurement
additional state data (e.g. head lights sensor specific additional data
on/off)
Table 1 - List of properties provided by simulation framework [25]

Also, environmental conditions can be considered as a further input for the

sensor model and need to be provided by the virtual environment. Required
information depends on the complexity of the model and may include
information about weather, the day-night cycle, road conditions, and structures
that could cause stray reflections. Sometimes these environmental conditions are
shown only as a graphical representation without any real effect on simulation
results.

27
Reasons for advanced sensor models for ADAS simulation:

• Access simulated data at any level of the processing chain for multiple
usages
o Raw sensor data
o Tracks/Objects data after signal processing
o Fused objects data
• Consider effects of the sensor technology
o Signal losses
o Detection noises
o Sensitivity
o Resolution
• Consider environment and targets interaction
o Material properties
o Multi-reflections
o Weather conditions
• Allow multi-sensor configuration
o Interferences
o Sensor fusion

Typical example of sensor output for AEB scenario is in the figure 1.15. In the
part 1 vehicle is constantly decelerating with a = - 4 m/s2 for t = 2.6 s. In the part
2 significant acceleration peak occurs with top value a = 8,9 m/s2 for t = 0.6 s.
This acceleration is caused by sensor blindness. For limited amount of time
sensor cannot see obstacle in front due to the pitch during braking. In part 3 full
brakes are applied, because sensor can see the obstacle again.

28
 1 2 3

Figure 1.15 - AEB braking and graph representing acceleration and pitch [27]

29
 1.4.1. Sensor modeling complexity

Each virtual simulation software has its own library of the sensor with
different level of realism. This mostly depends on the application of sensor and
on requirements. Figure 1.16 shows an example of sensors used in CarMaker and
how detailly modeled they are [30].
Ideal sensors are for rapid prototyping, proof of concept or verification. High
Fidelity (HiFi) Sensors for general function development and testing sensors are
more complex. Raw Signal Interfaces are for component/signal processing
development and testing. With increasing realism computational costs and
parametrization effort are increasing rapidly.

Figure 1.16 - Sensors in CarMaker [26]

1.4.2. Advanced RaDAR sensor modeling

The simulation of electromagnetic sensors can be achieved through dedicated

rendering process tuned to detect RaDAR targets or using ray tracing techniques
combined with the modeling of the RaDAR antenna. The strategy proposed here
is relying on a preliminary 3D characterization of the RaDAR devices obtained
using the CEM Solutions [28].
RaDAR sensors and devices are embedded in a simulation chain featuring
three various stages, (1) the modeling of the emitting/receiving antenna itself, (2)
the targets to be identified in the nearby environment and finally (3) the so-called
propagation channel allowing both to interact.

30
 The propagation of electromagnetic waves is usually handled through ray
tracing or other SBR techniques (Shooting and Bouncing Rays). Instead of using
an ideal (isotropic) radiating source, the propagation of electromagnetic waves is
weighted according to the direction being considered using the antenna
directivity. This chaining is quite loose but allows reaching quite easily a much
more realistic modeling of the sensor performance. The electromagnetic radiation
can be assumed in free space or with the RaDAR sensor located behind the plastic
bumper and interacting with near-by metallic parts or metallized paint coatings.

1.4.3. Modeling of a new generic virtual optical sensor

for ADAS prototyping

To achieve a physically realistic simulation of an optical camera, lighting

computation is a key challenge, since a biased input to the camera will
unavoidably lead to erroneous camera output. Ray Tracing, Radiosity and
Monte Carlo Analysis algorithms are identified approaches that focus on
different goals. To model the full optical chain, these methods are often combined
with adaptations or improvements yet are too computationally heavy [29].
To compute a physical-driven camera simulation, realistic information must
be applied to the camera model. It must be kept in mind that the optical
information to be provided to a camera may be different to human vision. Thus,
the rendering stage should compute realistic spectral luminance data based on
the geometrical description of the scene, lighting conditions, and material
properties.
To model a broad range of optical sensors with various levels of accuracy, a
mechanism of adapted rendering has been implemented in a simulation engine,
called multi-rendering. It then becomes possible to define and use different
rendering plug-ins adapted to specific requirements. For instance, a basic
graphical rendering for an optical sensor, or a more realistic optical sensor with
HDR (High Dynamic Range) textures, shadows, filters and tone mapping.
Currently, three optical rendering techniques are available. The first one
provides a classical 3D graphical engine rendering, the second one provides a
better shadow and light management, and the last one developed in the
framework of the eMotive project improves the physical realism of light
interaction with objects [29]. The engine allows applying various post-processing
effects to complete the rendering.

There are mechanisms for efficient environment modeling:

1) Lighting and interaction with object
2) Several types of filters for rain, fog, lights, blur and glow effects, color
management, lens distortion or depth of field.

31
 Chapter 2

2. Software
Within this diploma thesis is mainly used software CarMaker by company IPG
Automotive. CarMaker is real-time simulation software for virtual testing of
automobiles and light-duty vehicles. Using this software, we can accurately model
real-world test scenarios, including the entire surrounding environment, in the
virtual world. CarMaker is an open integration and test platform and can be applied
throughout the entire development process – from the model- to software- to
hardware- to vehicle-in-the-loop.

Figure 2.1 - CarMaker - virtual testing software [21]

32
2.1. CarMaker
CarMaker includes a complete model environment comprising an intelligent
driver model, a detailed vehicle model and highly flexible models for roads and
traffic. With the aid of this model environment, one can build complete and
realistic test scenarios with ease, taking the test run off the road and directly to
the computer. The event and maneuver-based testing method ensure that the
necessary flexibility and realistic execution of real-world test driving are also
features of virtual test driving.
A TestRun is a test scenario which collects all the information required to
parameterize the virtual vehicle environment and to start a simulation.
Depending on the complexity of the simulated test case, the TestRun composes
of a different number of modules. As a minimum requirement to be able to
simulate, the following modules must be parameterized within the TestRun:

• Vehicle: Definition of the vehicle data set used.

• Road: Parameterization of the test track.
• Maneuver: Mainly to specify the driver’s task.
• Driver: Set driver behavior (defensive, normal, aggressive, ...)

Figure 2.2 - CarMaker

33
 Additionally, the following modules can be defined in the TestRun,
depending on the field of application:
• Trailer: To simulate a test car with trailer configuration.
• Tires: Overwrite the default tire data set referred to the vehicle model.
• Traffic: Add other static or moving traffic objects.
• Environment: Configuration of the test environment with date, time and
ambient conditions.

In figure 2.3 is shown a list of available sensors. The majority of them are for
ADAS application, so we can test almost any setup of nowadays vehicles. This
approach can be used also for rest of car parts such as suspensions, steering,
powertrain etc.
A similar setup is in road definition like in figure 2.4. We can create any kind
of road including bridges, crossroads, traffic lights, sign and so on.

Figure 2.3 - CarMaker - car setup

34
 Figure 2.4 - CarMaker - road setup

2.2. CarMaker and other software tool

According the assignment CarMaker should be coupled with other software

tool. As the file interface was used Microsoft Excel. This tool will be used to
export data from CarMaker. These data will be GNSS coordinates and speed for
final test procedure validation in proving ground test.

Export

Figure 2.5 - Export of GNSS data from CarMaker to Microsoft Excel

35
2.3. Research of other automotive simulation tools

IPG Automotive is not only company developing vehicle simulation

software. For reference, other companies are introduced in following part.

2.3.1. dSpace - Automotive Simulation Models (ASM)

ASM is a tool suite for simulating combustion engines, vehicle dynamics,

electric components, and the traffic environment. The open Simulink models are
used for model-based function development and in ECU tests on a hardware-in-
the-loop (HIL) simulator.
The ASM concept consists of coordinated, combinable models of automotive
components. There is a vehicle model with a trailer, plus other ASMs for gasoline,
diesel and hybrid engines, exhaust systems, turbochargers, brake hydraulics,
electrical systems, electric motors, environment sensors, roads and traffic. The
ASMs support an entire range of simulations from individual components to
complex virtual traffic scenarios [33].

Figure 2.6 - dSpace - Automotive Simulation Models [33]

36
 2.3.2. CarSim

Mechanical Simulation produces and distributes software tools for

simulating and analyzing the dynamic behavior of motor vehicles in response to
steering, braking, and acceleration control inputs. CarSim is a commercial
software package that predicts the performance of vehicles in response to driver
controls (steering, throttle, brakes, clutch, and shifting) in a given environment
(road geometry, coefficients of friction, wind). CarSim is produced and
distributed by an American company, Mechanical Simulation Corporation, using
technology that originated at the University of Michigan Transportation
Research Institute (UMTRI) in Ann Arbor, Michigan [34].

Figure 2.7 – CarSim [35]

37
 Chapter 3

3. Simulation of predefined driving

scenarios
All simulated driving scenarios are based on dissertation [6]. There are 11
scenarios altogether which were simulated, parametrized and evaluated. Most of
them are designed to test ADAS systems in general – mainly AEB, ACC or CMS
systems. Parametrization is done with respect to vehicle dynamics. The result of
every simulation is in the form of geodetic coordinates and speed for final test
procedure validation in proving ground test.

3.1. Test track description

Test track used in these simulations were inspired by the airport Hradčany u
Mimoně. This airport is often used as the proving ground test track for many
vehicle systems.
Test track is designed with the same dimensions. All scenarios were done at
the main runway with a length of 2700 m and with 90 m. Optional features are
lanes and surrounding done by myself. Lane has width of 4 m. The whole track
is presented in figure 3.1.
The advantage of modeling this track is, that we can set it into the real map
by GPS coordinates – figure 3.2. This means we can export these coordinates
directly or show them through Google Earth and see the longitudinal or lateral
movement of eGo vehicle and its speed – figure 3.3.

38
Figure 3.2 – Test track Hradčany u Mimoně in CarMaker

Figure 3.1 - CarMaker and GPS

39
 Figure 3.3 - Google Earth view from CarMaker

3.2. Maneuver description

The concept of CarMaker for the driving scenario is the following:
There is one maneuver definition, which is split into several maneuver steps (e.g.:
acceleration, braking, ...). These maneuver steps are called minimaneuvers. Each
minimaneuver is composed of:
- longitudinal dynamic actions: accelerating, braking, gear shifting
- lateral dynamic actions: steering
- additional actions, defined by a list of special minimaneuver commands of
a very easy script language.

In figure 3.4, we can see maneuver definition. To build a driving scenario, we

must add and parameterize successively the various maneuver steps necessary
to control the vehicle as we want. The list of the maneuver steps is displayed and
can be built in box 1 of Figure 3.4 at the left side of the Maneuver dialog. After
creating a maneuver step, the actions need to be defined. Each minimaneuver
consists of a duration (box 2 in Figure 3.4) and a description of the driver’s task,
separated in longitudinal and lateral dynamics (box 3+4 in Figure 3.4).

40
 Figure 3.4 - Maneuver dialog

3.3. Vehicle description

Each vehicle is a dynamic model of existing car. These models are not
validated, so there can be differences in vehicle behavior despite reality.
For our purposes, we use 2 vehicles:

• DemoCar VW Beetle
• Demo BMW 5-series

Volkswagen Beetle has setup for AEB testing and BMW 5-series for ACC
testing. Vehicle data set has many possibilities of tuning of the vehicle starting
with body, engine, suspension, steering, tires, brakes, powertrain, aerodynamics
and sensors along with vehicle control. Last two are most important for our
applications.

Volkswagen Beetle uses General Longitudinal Control for controlling the

vehicle. The simple Generic Longitudinal Control model contains two
functionalities: Autonomous Emergency Braking and Forward Collision
Warning, which are explained below.

41
• Autonomous emergency braking (AEB)
The Autonomous Emergency Braking system has the task to decelerate
safely the vehicle to the velocity of the target object ahead. For this, the
system compares the time-to-collision ttc with a time-threshold-brake ttb to
decide if a braking intervention is required.

• Forward Collision Warning (FCW)

The Forward Collision Warning system has the task to warn the driver by
different degrees of warning level if time-to-collision falls below the
defined time threshold. The simple generic model supports two different
warning levels, which are activated before the AEB reaction.

To ensure correct behavior camera is used as a sensor for scanning area in

front of the vehicle. The camera has its own place on the vehicle as well as its
working parameters like range and horizontal and vertical aperture – see the
figure 3.5 and 3.6.

Figure 3.5 - VW Beetle sensor setup

42
 Figure 3.6 - VW Beetle vehicle control

BMW 5-series uses Acceleration control + ACC for controlling the vehicle. ACC
controls the longitudinal acceleration of the vehicle by changing the position of the
brake and gas pedal. If ACC is deactivated there is no manipulation of the pedal
position by the controller – figure 3.7. The controller distinguishes two cases:
• If there is no target detected, the velocity will be controlled.
• If there is a relevant target detected, the distance will be controlled.

Figure 3.7 - Closed loop of the ACC-Controller

43
 This controller uses a PI-Controller. The desired longitudinal acceleration can be
calculated in different manners: using CarMakers built-in ACC-Controller, via
Direct Variable Access or using a user implemented function.
To ensure correct behavior of the RaDAR is used as a sensor for scanning area in
front of the vehicle. RaDAR has its own place on the vehicle as well as its working
parameters like range and horizontal and vertical aperture – see the figure 3.8 and
3.9.

Figure 3.8 - BMW 5-series sensor setup

44
Figure 3.9 - BMW 5-series vehicle control

45
3.4. Description of driving scenarios
Every driving scenario has been simulated individually. A detailed
description of each is below. All these scenarios are based on dissertation [11]
from my supervisor.

3.4.1. T02 - CTU 02/2013 B, C - Limitations to another

maneuver

This test run is focused on the analysis of the behavior of the automatic
emergency brake system and the adaptive cruise control reaction. Reactions of
the eGo vehicle being tested always behind the target vehicle – case B. Distance
of about 15 m behind the target vehicle is maintained and no automatic braking
response is expected.
In the Adaptive Cruise Control, however, the reaction to the newly
discovered obstacle is desirable - the test vehicle should start to brake. The cruise
speed is set at 5 km/h higher than the speed of the target vehicle and its distance
from the adaptive cruise control system is set to the shortest possible. These tests
are marked T02 - CTU 02/2013 B for the Integrated Safety System Test and T02 -
CTU 02/2013 C for Adaptive Cruise Control.

Figure 3.11 - T02 - CTU 02/2013 B

Figure 3.10 - T02 - CTU 02/2013 C

46
 3.4.2. T05 - CTU 02/2013 E - Adaptive cruise control
adaptation

The test is focused on adaptive cruise control adaptation when driving multiple
vehicles with this system in a row. For all vehicles, the speed at the beginning is set
to 70 km/h, then the first vehicle will slow down to 50 km/h and the response of
other cars is monitored. After stabilization of the speed, the first vehicle accelerates
in the same way to 70 km/h and the response of other vehicles is re-analysed. All
vehicles in the row traveling behind the first vehicle, have a cruise control always
set to a speed of 10 km/h higher than the vehicle ahead. This test is labeled as T05 -
CTU 02/2013 E.

Figure 3.12 - T05 - CTU 02/2013 E

3.4.3. T06 - CTU 02/2013 F - Secure and predictable

vehicle interaction

The test is focused on the analysis of the behavior of the ADAS system in the
context of other traffic. The behavior of the interactive technology interface of the
autonomous system and other vehicles is evaluated. The eGo vehicle maintains a
constant speed of 80 km/h through adaptive cruise control which is set at a
maximum distance from the vehicle in front. Outside the axis of the eGo vehicle,
the target vehicle moves at the same constant speed. After the distance between
vehicles is between 15 and 20 m, the eGo vehicle moves to the target lane. Vehicle
and the alignment of the distance are monitored to match the set distance. This
should be smooth without using the car's brakes. The test is designated as T06 -
CTU 02/2013 F.

Figure 3.13 - T06 - CTU 02/2013 F

47
 3.4.4. T07 - CTU 02/2013 G - Consistency of system
behavior

The purpose of the test is to verify the behavior of the automatic emergency
brake system according to the manufacturer's specification. The tested vehicle
again moves outside the obstacle axis with a speed of 20 km/h, maintained by the
driver, and approximately 100 m before the obstacle enters its axis. The
manufacturer's prescribed reaction response is expected, for example, automatic
braking before the obstacle, while the driver does not change the driving speed.

Figure 3.14 - T07 - CTU 02/2013 G

3.4.5. T08 – ES 347/2012 A - Recognizing the trajectory

between standing vehicles

The first standardized test is part of European Union Regulation No. 347/2012,
prescribing the characteristics of the automatic braking system for trucks and
buses. The test verifies whether the detection system can recognize the space
between two side-by-side standing vehicles whose rear parts are aligned in one
plane.

Figure 3.15 - T08 - ES 347/2012 A

48
 The prescription defines the passage without the adaptive cruise control only
for automatic braking systems. For greater clarity and the possibility of merging
similar tests, the adaptive cruise control is on and set to maintain the 50km/h with
maximum distance.

3.4.6. T12 - ISO 15623 B - Recognition of the target

vehicle from two consecutive targets

The test is one of the tests defined by ISO 15623. The test determines whether
the eGo vehicle recognizes two near-running vehicles that do not overlap
completely. During the test, the main target vehicle (center) is driven at a constant
speed outside of the eGo driving axis (however, it is necessary to reach at least 0.5 m
of its width in the test vehicle strip). The eGo vehicle accelerates until the warning
system alerts and then decelerates until the warning system disappears. Then
begins to decelerate the middle target vehicle and decelerates until the warning
system of the eGo vehicle again responds.

Figure 3.16 - T 12 - ISO 15623 B

3.4.7. T15 - ISO 22178 B: Column slow ride: Target

vehicle recognition from overtaking car

The experiment is defined by ISO 22178 and focuses on the ability of the
detection subsystem to distinguish between parallel driving vehicles. The column

Figure 3.17 - T15 - ISO 22178 B

49
overtakes a faster vehicle that slows down at the target vehicle's speed and slows
down further. The eGo vehicle maintaining speed through the adaptive cruise
control and does not have respond to the overtaking vehicle.

3.4.8. T16 - ISO 22178 C: Slow drive in the column: the

target vehicle leaves the column
The test is again defined by ISO 22178 and is aimed at detecting the new target
vehicle. In a column of three vehicles traveling with minimum intervals between
them, the middle target vehicle decides to leave the column. The eGo vehicle is set
to maintain a minimum distance and the cruise control has a set speed
corresponding to the minimum possible, but at least 5 km/h more than the speed
of the column. The eGo vehicle must continuously link to the new target vehicle.

Figure 3.18 - T16 - ISO 22178 C

3.4.9. T18 - ISO 22179 A: Tracking the target vehicle to

stop

The test is based on ISO 22179 and is focused on tracking the target vehicle via
adaptive cruise control until it stops if the manufacturer specifies this function. The
test combines a column test with an adaptive cruise control running from zero
speed. The faster eGo vehicle arrives at the slower target vehicle, which then
continuously decelerates until it stops.

Figure 3.19 - T18 - ISO 22179 A

50
 3.4.10. T19 - ISO 22179 B: Resolution of the target vehicle
from the overtaking car
The test is based on the ISO 22179 standard. It is focused on the analysis of the
ability to discretize two parallel-running vehicles without stabilizing the relative
position of the target and the parallel vehicle. The objective is to verify the
capabilities of the detection subsystem. The test was performed according to the
specification in the standard. The eGo vehicle, with the adaptive cruise control on,
set at a higher speed than the target vehicle, moves behind the target vehicle. The
target and eGo vehicles are gradually overtaking a parallel slower car. The eGo
vehicle does not have responded to the overtaken vehicle.

Figure 3.20 - T19 - ISO 22179 B

3.5. Parametrization of driving scenarios

CarMaker offers different possibilities to make simulation work a lot easier, for
example, the test automation. Using it, we perform simulations with varying
parameters completely autonomously. This parametrization was done by
CarMaker Test Manager.
A test series in the Test Manager basically consists of TestRuns that are executed
automatically one after another. However, the Test Manager offers a lot of
functionalities to optimize the preparation, execution, and analysis of TestRuns: We
can use variations to modify parameters of a TestRun instead of creating a TestRun
for each scenario. We can add script files to define certain actions which should be
executed at the beginning or at the end of each simulation. The definition of criteria
can be used to judge the results of a simulation at one glance or even to abort the
execution of the test series once a user defined condition is met.

51
 All the TestRuns, variations and scripts that make up a test series in the Test
Manager are executed consecutively starting from top to bottom. An overview of
the execution order is given in the figure 3.21, marked as box A in the picture below.
In box B, we can find a description of the current test series (if activated under
View) or we can place settings such as select a TestRun or enter a value for a
variation.

Figure 3.21 - Clear view (A) and description window (B) of the Test Manager GUI

Every driving scenario has been parametrized to three cases from A to C. These
cases have different values for every variable. These values were chosen with
regards to vehicle dynamics and driving scenario definition.

Every TestRun will be described by following parameters:

• TestRun: name of the test run in CarMaker

• Car: name of the car in CarMaker
• Test manager: name of the test manager in CarMaker
• Parametrized variables and its values

52
 Explanatory notes for variables with units:

Variable Unit Description

Deceleration [m/s2] deceleration of target vehicle
Distance_eGo_Target [m, s] longitudinal distance between eGo and target vehicle in meters
or seconds
Distance_eGo_SCT [m] longitudinal distance between eGo vehicle and soft crash target
Distance_Target_SCT [m] longitudinal distance between target vehicle and soft crash
target
Distance_target_target [m] lateral distance between two targets driving axis
Distance_target_target1 [m] lateral distance between two targets driving axis in negative
values
Friction_coef [1] friction coefficient of road surface
Sensor_range [m] longitudinal sensor range
Sensor_view_angle_horizontal [deg] horizontal sensor view angle
Sensor_view_angle_vertical [deg] vertical sensor view angle
Speed [km/h] speed of eGo vehicle
Speed_parallel [km/h] speed of parallel driving vehicle
Speed_target [km/h] speed of target vehicle
Speed_traffic [km/h] speed of traffic object
Target_overlap [m] lateral distance between target driving axis and lane axis

3.5.1. T02 - CTU 02/2013 B, C - Limitations to another

maneuver

TestRun: T02_CTU_02_2013B_testrun
Car: DemoCar_EuroNCAP_GLC_T02_CTU_02_2013B
Test manager: Parametrization_ T02_CTU_02_2013B.ts

Name of parameters Case A Case B Case C

Distance_eGo_Target [m] 20 15 10
Distance_Target_SCT 30 25 20
Friction_coef 0.5 0.8 1
Input Sensor_range 20 40 80
Sensor_view_angle_horizontal 25 35 45
Sensor_view_angle_vertical 25 35 45
Speed 65 70 75
Output Distance_eGo_SCT 29 35 28

53
TestRun: T02_CTU_02_2013C_testrun
Car: Demo_BMW_5_ACC_T02_CTU_02_2013C
Test manager: Parametrization_ T02_CTU_02_2013C.ts

Name of parameters Case A Case B Case C

Distance_eGo_Target [s] 3 2 1
Distance_Target_SCT 30 25 20
Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input
Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 65 70 75
Speed_traffic 60 65 70
Output Distance_eGo_SCT 25 25 25

3.5.2. T05 - CTU 02/2013 E - Adaptive cruise control

adaptation

TestRun: T05_CTU_02_2013E_testrun
Car: Demo_BMW_5_ACC_T05_CTU_02_2013E
Test manager: Parametrization_T05_CTU_02_2013E.ts

Name of parameters Case A Case B Case C

Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input
Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16

54
3.5.3. T06 - CTU 02/2013 F - Secure and predictable
vehicle interaction

TestRun: T06_CTU_02_2013F_testrun
Car: Demo_BMW_5_ACC_T06_CTU_02_2013F
Test manager: Parametrization_T06_CTU_02_2013E.ts

Name of parameters Case A Case B Case C

Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 75 80 85
Output Distance_eGo_Target 44 32 19

3.5.4. T07 - CTU 02/2013 G - Consistency of system

behavior

TestRun: T07_CTU_02_2013G_testrun
Car: DemoCar_EuroNCAP_GLC_T07_CTU_02_2013G
Test manager: Parametrization_T07_CTU_02_2013G.ts

Name of parameters Case A Case B Case C

Friction_coef 0.5 0.8 1
Sensor_range 20 40 80
Input Sensor_view_angle_horizontal 25 35 45
Sensor_view_angle_vertical 25 35 45
Speed 15 20 25

55
3.5.5. T08 – ES 347/2012 A - Recognizing the trajectory
between standing vehicles

TestRun: T08_ES_347_2012A_testrun
Car: Demo_BMW_5_ACC_T08_ES_347_2012A
Test manager: Parametrization_T08_ES_347_2012A.ts

Name of parameters Case A Case B Case C

Distance_target_target 2.2 3 4
Distance_target_target1 -2.2 -3 -4
Friction_coef 0.5 0.8 1
Input Sensor_range 100 150 200
Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 45 50 55
Output Actual gap [m] 2.65 4.5 6.3

3.5.6. T12 - ISO 15623 B - Recognition of the target

vehicle from two consecutive targets

TestRun: T12_ISO_15623B_testrun
Car: Demo_BMW_5_ACC_T12_ISO_15623B
Test manager: Parametrization_T12_ISO_15623B.ts

Name of parameters Case A Case B Case C

Distance_eGo_Target [s] 1 2 3
Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 45 50 55
Target_overlap -2 -1.5 -1
Output Actual overlap [m] 0.85 1.35 1.85

56
3.5.7. T15 - ISO 22178 B: Column slow ride: Target
vehicle recognition from overtaking car

TestRun: T15_ISO_22178B_testrun
Car: Demo_BMW_5_ACC_ T15_ISO_22178B
Test manager: Parametrization_ T15_ISO_22178B.ts

Name of parameters Case A Case B Case C

Deceleration -1 -3 -5
Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 20 25 30
Speed_target 30 35 40

3.5.8. T16 - ISO 22178 C: Slow drive in the column: the

target vehicle leaves the column
TestRun: T16_ISO_22178C_testrun
Car: Demo_BMW_5_ACC_ T16_ISO_22178C
Test manager: Parametrization_ T16_ISO_22178C.ts

Name of parameters Case A Case B Case C

Distance_eGo_Target [s] 1 1.5 2
Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input
Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 20 25 30

57
3.5.9. T18 - ISO 22179 A: Tracking the target vehicle to
stop

TestRun: T18_ISO_22179A_testrun
Car: Demo_BMW_5_ACC_ T18_ISO_22179A
Test manager: Parametrization_ T18_ISO_22179A.ts

Name of parameters Case A Case B Case C

Deceleration -1 -3 -5
Distance_eGo_Target [s] 2 3 4
Friction_coef 0.5 0.8 1
Input Sensor_range 100 150 200
Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed 60 65 70

3.5.10. T19 - ISO 22179 B: Resolution of the target vehicle

from the overtaking car
TestRun: T19_ISO_22179B_testrun
Car: Demo_BMW_5_ACC_ T19_ISO_22179B
Test manager: Parametrization_ T19_ISO_22179B.ts

Name of parameters Case A Case B Case C

Distance_target_target 3 3,5 4
Friction_coef 0.5 0.8 1
Sensor_range 100 150 200
Input Sensor_view_angle_horizontal 2 4 6
Sensor_view_angle_vertical 10 13 16
Speed_parallel 69 79 89
Speed_target 80 90 100

58
3.6. Evaluation of driving scenarios
The evaluation was done with help of IPGMovie tool, which graphically
represents all the simulations and IPGControl. IPGControl offers the functionality
of an online result management. This means that the current simulation data is
provided without delay, which enables us to display diagrams directly during the
simulation.

3.6.1. T02 - CTU 02/2013 B, C - Limitations to another

maneuver

The goal of this test for T02 – CTU 02/2013 B was to test reactions of AEB
system. eGo vehicle should not start braking when target vehicle exits its lane and
new static target (SCT) appears because eGo vehicle exits this lane also.

Limit distances (eGo does not brake) between SCT and eGo vehicle are:
Name of parameter Case A Case B Case C
LongCtrl.AEB.dDist [m] 18.4 25 9

Figure 3.22 – eGo and SCT driving parameters – Case B

59
 (1) LongCtrl.FCW.SwitchedOn: Flat if FCW system is switched on
(2) LongCtrl.FCW.WarnLevel: Warning level of FCW system: 0=no warning, 1-
2=warning level 1-2
(3) LongCtrl.AEB.IsActive: Flat if AEB system is active (=braking)
(4) LongCtrl.AEB.SwitchedOn: Flat if AEB system is switched on
(5) DM.Brake: Brake/decelerator activity, relative pedal force (0..1)
(6) LongCtrl.AEB.dDist [m]: Relative distance to relevant target object
(7) LongCtrl.AEB.Time2Collision [s]: Time to collision with the target vehicle
(7) LongCtrl.AEB.Time2Brake [s]: Time threshold to brake to equal velocity of the
target object

This test has a limit of 25 m and it has been reached in all of these cases. In
Case C, the relative distance was shortest - 9 meters to the target vehicle. In Case B,
the relative distance was 25 m, so on the limit, but still acceptable. Variable
DM.Brake represent inactivity of braking pedal during whole simulation.

For version T02 – CTU 02/2013 C limit of 25 m was met. The required behavior
of the vehicle was braking when it recognizes a new target. This behavior was met
in every test case. DM.Brake shows that vehicle was braking for 1.5 s

Figure 3.23 - eGo driving parameters for ACC - Case B

60
 (1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated
(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) DM.Brake: Brake/decelerator activity, relative pedal force (0..1)
(4) AccelCtrl.ACC.Time2Collision [s]: Time to collision with the target vehicle
(5) AccelCtrl.ACC.DesiredDist [m]: Desired distance to the target vehicle
(6) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)

3.6.2. T05 - CTU 02/2013 E - Adaptive cruise control

adaptation

The goal of this test was to verify adaptation of ACC. The response of other cars
was monitored. In every case, ACC of every car adapts to the new situation. ACC
of target vehicles has default setup, which cannot be tuned, but eGo vehicle has the
possibility to improve the response of ACC. In the figure 3.25 is described the list
of parameters. For Case B graph with speeds is plotted in figure 3.24. In the first
part vehicles have default starting positions and must create 1.5 s gaps between
each other. Traffic object T04 is leading the column and rest is setting up right
distance. In part two all speeds are same and vehicles travel simultaneously. In part
three it is clearly visible, that target T04 starts braking first and every following
object copies its behavior until steady state in part four. In the last fifth part vehicles
start to accelerate again.

2
5
1 3 4

Figure 3.24 - Speeds of each vehicle during simulation - Case B

61
 Figure 3.25 – ACC parameters setup

3.6.3. T06 - CTU 02/2013 F - Secure and predictable

vehicle interaction

The goal of this test was the analysis of the behavior of the autonomous system
in the context of other traffic. eGo vehicle with ACC set to the maximum distance
merges into target’s lane 15 – 20 m behind it. The reaction of ACC controller is
monitored. Setting up of required ACC distance should be done continuously and
without using of brakes.

Limit distances (eGo does not brake) between target and eGo vehicle are:
Name of parameter Case A Case B Case C
Distance_eGo_target [m] 44 32 19

ACC maximum distance is set to 3 s gap between eGo and target. For smoother
spacing acceleration controller factor, I [-] is changed from 0.001 to 0.0001 and
minimal distance is 10 m – figure 3.26. In the default setup merging was always
accompanied by braking independently on distance between eGo and target. After
tuning controller factor I, values in the table were reached. Only for Case C limit
between 15 – 20 m was met. Rest of TestRuns don’t suit.

62
 Figure 3.27 – ACC parameters tuning

Figure 3.26 – ACC behavior of eGo vehicle – Case B

63
 (1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated
(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) DM.Brake: Brake/decelerator activity, relative pedal force (0..1)
(4) AccelCtrl.ACC.DesiredDist [m]: Desired distance to the target vehicle
(5) Car.v [km/h]: Absolute velocity of eGo vehicle connected body
(6) AccelCtrl.ACC.DesiredTGap [s]: Desired time distance to the target vehicle

3.6.4. T07 - CTU 02/2013 G - Consistency of system

behavior

The goal of the test is to verify the behavior of the automatic emergency brake
system according to the manufacturer's specification. In all three cases, AEB system
avoided a collision. Figure 3.28 shows moment right before upcoming collision.

Figure 3.28 -FCW and AEB control factors - Case B

64
 In figure 3.28 is described Case B with time sample of 6 s when collision
situation occurs. At the time 86 s variable LongCtrl.AEB.Time2Collision is
calculated for about 7 s and it is linearly decreasing along with LongCtrl.AEB.dDist.
At the time 90.4 s LongCtrl.FCW.WarnLevel 1 is active and at the time 91.4 s
LongCtrl.FCW.WarnLevel 2 is active. When LongCtrl.AEB.Time2Collision and
LongCtrl.AEB.Time2Brake are equal LongCtrl.AEB.IsActive is turned on and
vehicle starts braking.

(1) LongCtrl.FCW.SwitchedOn: Flat if FCW system is switched on

(2) LongCtrl.FCW.WarnLevel: Warning level of FCW system: 0=no warning, 1-
2=warning level 1-2
(3) LongCtrl.AEB.IsActive: Flat if AEB system is active (=braking)
(4) LongCtrl.AEB.SwitchedOn: Flat if AEB system is switched on
(5) LongCtrl.AEB.dDist [m]: Relative distance to relevant target object
(6) LongCtrl.AEB.Time2Collision [s]: Time to collision with the target vehicle
(6) LongCtrl.AEB.Time2Brake [s]: Time threshold to brake to equal velocity of
the target object

3.6.5. T08 – ES 347/2012 A - Recognizing the trajectory

between standing vehicles

The goal of the test is to verify whether the detection system can recognize the
space between two side-by-side vehicles whose rear parts are aligned in one plane.
Values in the table below representing the lateral distance between target
driving axis and eGo driving axis. Actual gaps between vehicles are slightly
different.

Limit distances between two targets are:

Name of parameter Case A Case B Case C
Actual gap [m] 2.65 4.5 6.3
Distance_target_target [m] 2.2 3.1 4

Smallest gap between two side-by-side standing target vehicle, which eGo
vehicle can go through is 2.65 m. Smaller gap is evaluated as an obstacle and vehicle
stops. In all three cases, eGo passed.

65
 3.6.6. T12 - ISO 15623 B - Recognition of the target
vehicle from two consecutive targets

The goal of the test is to determine whether the eGo vehicle recognizes two
near-running vehicles that do not overlap completely.
During Case A eGo vehicle does not manage to break when the target starts to
decelerate. This is caused by small eGo and target time gap 1 s and low friction
coefficient 0.5 s. Target overlap does not have any effect on this failure.
In rest of cases, everything works fine and eGo reacts correctly and starts
braking.

Figure 3.29 – eGo behavior during target’ braking – Case B

(1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated

(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) AccelCtrl.ACC.Time2Collision [s]: Time to collision with the target vehicle
(4) DASensor.RadarL.relvTgt.Id: Traffic object number of the relevant target
(integer)
(5) Car.ax [m/s2]: Translational acceleration of eGo vehicle connected body

66
 Figure 3.29 shows whole Case B TestRun. AccelCtrl.ACC.IsActive represents
activated ACC control. DASensor.RadarL.relvTgt.dtct show that some relevant
target(s) is detected. ACC reacts to target behavior with braking. This braking is
represented by Car.ax – red curve. DASensor.RadarL.relvTgt.Id detect for whole
period of simulation 2 targets altogether.

3.6.7. T15 - ISO 22178 B: Column slow ride: Target

vehicle recognition from overtaking car

The goal is to test the ability of the detection subsystem to distinguish between
parallel driving vehicles. In all three cases, eGo vehicle acts correctly and does not
react to parallel driving target.

Figure 3.30 - eGo and target behavior during maneuver - Case B

67
 (1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated
(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) DASensor.RadarL.relvTgt.Id: Traffic object number of the relevant target
(integer)
(4) Car.ax [m/s2]: Translational acceleration of eGo vehicle connected body
(5) Traffic.T03.LongAcc [m/s2]: Longitudinal acceleration of the traffic object in
object frame

Figure 3.30 shows whole simulation time of Case B. AccelCtrl.ACC.IsActive

represents activated ACC control. DASensor.RadarL.relvTgt.dtct show that some
relevant target(s) is detected. At the time 45 s overtaking vehicle starts braking and
eGo vehicle continue its path. There is visible deceleration of eGo vehicle when
overtaking vehicle starts braking, but this is not caused by brakes, but because
desired distance of ACC is too short and eGo is braking by engine to maintain the
gap.

3.6.8. T16 - ISO 22178 C: Slow drive in the column: the

target vehicle leaves the column

The test is aimed at detecting the new target vehicle. eGo vehicle always
continuously accepts new target.

Figure 3.31 shows whole simulation time of Case B. AccelCtrl.ACC.IsActive

represents activated ACC control. DASensor.RadarL.relvTgt.dtct show that some
relevant target(s) is detected. DASensor.RadarL.relvTgt.Id detect for 24 s only one
target and after that 2 targets altogether. Curve Car.ax representing acceleration of
eGo to maintain AccelCtrl.ACC.DesiredTGap 1.5 s.

(1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated

(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) DASensor.RadarL.relvTgt.Id: Traffic object number of the relevant target
(integer)
(4) Car.ax [m/s2]: Translational acceleration of eGo vehicle connected body
(5) AccelCtrl.ACC.DesiredTGap [s]: Desired time distance to the target vehicle

68
 Figure 3.31 – eGo detecting new target and set desired distance – Case B

3.6.9. T18 - ISO 22179 A: Tracking the target vehicle to

stop

The goal of the test is focused on tracking the target vehicle via adaptive cruise
control until it stops.
Except for Case A eGo vehicle always managed to stop successfully without
colliding with the target vehicle. Case A had a crash and the reason is small time
gap 2 s and low friction coefficient 0.5.

69
 Figure 3.32 – eGo reaction to decelerating target – Case B

(1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated

(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) Car.ax [m/s2]: Translational acceleration of eGo vehicle connected body
(4) AccelCtrl.ACC.DesiredTGap [s]: Desired time distance to the target vehicle
(5) Traffic.T03.LongAcc [m/s2]: Longitudinal acceleration of the traffic object in
object frame

Figure 3.32 shows whole simulation time of Case B. AccelCtrl.ACC.IsActive

represents activated ACC control. DASensor.RadarL.relvTgt.dtct show that some
relevant target(s) is detected. At the time 50 s target vehicle starts braking and eGo
reacts with braking as well. Target deceleration reaches value -3 m/s2 and eGo
deceleration peak value is -2.6 m/s2.

70
 3.6.10. T19 - ISO 22179 B: Resolution of the target vehicle
from the overtaking car
The goal of the test is to analyze the ability to discretize two parallel-running
vehicles without stabilizing the relative position of the target and the parallel
vehicle. eGo vehicle never responds to the overtaken vehicle.

Figure 3.33 -eGo and parallel vehicle speed profile – Case B

(1) AccelCtrl.ACC.IsActive: Flat if the ACC controller is activated

(2) DASensor.RadarL.relvTgt.dtct: Flat if a relevant target is detected (boolean)
(3) DASensor.RadarL.relvTgt.Id: Traffic object number of the relevant target
(integer)
(4) Car.v [km/h]: Absolute velocity of eGo vehicle connected body
(5) Traffic.T02.LongVel [km/h]: Longitudinal velocity of the traffic object in
object frame

Figure 3.33 shows whole simulation. eGo vehicle does not respond to slower
overtaken vehicle by any kind of action and follow target vehicle continuously.

71
3.7. GPS coordinates as results of simulations
Every single scenario provides us results in form of speed and World Geodetic
System - WGS 84 coordinates, which can, for example, be used with Google Earth.
These values are exported from CarMaker into Excel sheet.
Due to the small driving ranges (max. 1000 m) these coordinates do not change
so much, there are only minor differences.

Example of 0.1 s sample:

Time Car.Road.GCS.Elev Car.Road.GCS.Lat Car.Road.GCS.Long Car.v

s m deg deg km/h
62.871 278 50.61844668 14.74577237 19.99999922
62.881 278 50.61844674 14.74577159 19.99999922
62.891 278 50.6184468 14.74577081 19.99999922
62.901 278 50.61844685 14.74577003 19.99999922
62.911 278 50.61844691 14.74576925 19.99999922
62.921 278 50.61844697 14.74576847 19.99999922
62.931 278 50.61844702 14.74576769 19.99999922
62.941 278 50.61844708 14.74576691 19.99999922
62.951 278 50.61844714 14.74576613 19.99999922
62.961 278 50.61844719 14.74576535 19.99999922
62.971 278 50.61844725 14.74576457 19.99999922

Output variables are specified below:

GCS Lat [deg]: Specifies the latitude of the geographic coordinates of the reference
point.
GCS Long [deg]: Specifies the longitude of the geographic coordinates of the
reference point.
GCS Height [m]: Specifies the elevation of the geographic coordinates of the
reference point.
Car Velocity [km/h]: velocity of vehicle

These results can be used for procedure validation in proving ground test.
Another option is to use Differential GPS with different output quantities.

72
 Chapter 4

4. Conclusion

4.1. Contributions
This master thesis introduces new simulation possibilities for ADAS system
testing with help of IPG CarMaker software tool. We can simulate almost any kind
of driving scenario with minimal costs and relevant results. The most crucial things
are vehicle models, these should be ideally the same as a real vehicle for getting
correct results. We used predefined models.
Road modeling is another very important part of the simulation because we can
create any kind road with specific parameters (friction coefficient, elevation, curbs
etc.). GPS coordinates can be used in both ways for import and export.
All predefined driving scenarios were successfully simulated and
parametrized.

4.2. Assignment
The first part of the assignment was to do research of state-of-the-art in the field
of ADAS system software testing with regards to sensor physics modeling. This
part was fully accomplished with sensor research in general. This means types of
sensor and its usage in vehicles or typical parameters. Sensor physics modeling is
pretty much the know-how of companies developing these systems, but few
remarks about modeling in general are introduced along with modeling
complexity.
The second part of the thesis was to model predefined scenarios in IPG
CarMaker and coupling with other software tools. As another software tool was
chosen Microsoft Excel. Along with modeling, parameterization with respect to
vehicle dynamics was necessary. All scenarios were simulated with success.
The last part was export of geodetic coordinates and speeds for final test
procedure validation in proving ground test. These results were exported for every
single scenario.

4.3. Future work

The upcoming goal can be set in vehicle model development in CarMaker and
validation of ADAS systems. Vehicle models are not properly validated so we
cannot judge if these results are good enough or not. Dynamic vehicle model is
difficult to develop and depends on requirements or our expectation of reality.

73
List of sources
[1] What is an Automatic Braking System? [online]. [cit. 2017-07-25] Available at:
https://www.lifewire.com/what-is-automatic-braking-system-534823.
[2] Traffic sign recognition [online]. [cit. 2017-07-25] Available at:
https://www.cartrade.com/blog/2015/car-automobile-technology/traffic-signs-
recognition-1309.html
[3] Top 20 Automotive Advanced Driver Assistance Systems (ADAS) Companies
2016 [online]. [cit. 2017-07-25] Available at: http://1url.cz/htW8D
[4] Decoding Blind Spot Detection and Warning Systems [online]. [cit. 2017-07-25]
Available at: https://www.lifewire.com/decoding-blind-spot-detection-534803
[5] What Are Lane Departure Warning Systems? [online]. [cit. 2017-07-25] Available
at: https://www.lifewire.com/what-are-lane-departure-warning-systems-534822
[6] JIROVSKÝ. Václav. Metodika hodnocení systémů integrované bezpečnosti
osobních automobilů. Praha. 2015. Disertační práce. České Vysoké Učení Technické v
Praze
[7] Sensor Models for Automated and Assisted Driving – A Testing Concept. 2017.
Dr. Andreas Höfer. IPG Automotive GmbH
[8] Advanced Driver Assistance Systems [online]. [cit. 2017-07-25] Available at:
https://www.continental-automotive.com/en-gl/Passenger-Cars/Chassis-
Safety/Advanced-Driver-Assistance-Systems
[9] What is adaptive cruise control and how does it work? [cit. 2017-07-25] Available
at: http://www.extremetech.com/extreme/157172-what-is-adaptive-cruise- control-
and-how-does-it-work
[10] Blind spot detection: Car tech that watches where you can’t [online]. [cit. 2017-
07-27] Available at: http://www.extremetech.com/extreme/165742-blind-spot-
detection- car-tech-that-watches-where-you-cant
[11] Type of radars on vehicles [online]. [cit. 2017-07-27] Available at:
http://www.fujitsu-ten.com/business/automotive/lineup/index.html
[12] Lidar Continental [online]. [cit. 2017-07-27] Available at:
http://www.allaboutcircuits.com/uploads/articles/contental_driving_sensor9.jpg
[13] ABS (Anti-lock Braking System) [online]. [cit. 2017-07-27] Available at:
http://www.autolexicon.net/cs/articles/abs-anti-lock-braking- system/
[14] Autonomous Emergency Braking [online]. [cit. 2017-07-25] Available at:
https://www.euroncap.com/en/vehicle-safety/the-rewards-
explained/autonomous-emergency-braking

74
[15] Subaru Adaptive Cruise Control [online]. [cit. 2017-07-25] Available at:
http://www.subaru.com.au/about/eyesight/adaptive-cruise-control
[16] ACC [online]. [cit. 2017-07-25] Available at: http://www.proctorcars.com/how-
does-adaptive-cruise-control-work/
[17] Active cruise control systems: Road trip tech series #1 [online]. [cit. 2017-07-17]
Available at: http://openroadautogroup.com/blog/active-cruise-control-systems
[18] Lidars [online]. [cit. 2017-07-27] Available at: https://www.continental-
automotive.com/en-gl/Passenger-Cars/Chassis-Safety/Advanced-Driver-
Assistance-Systems/Lidars
[19] Camera Continental [online]. [cit. 2017-07-27] Available at:
https://www.continental-automotive.com/en-gl/Passenger-Cars/Chassis-
Safety/Advanced-Driver-Assistance-Systems/Cameras
[20] An introduction to ultrasonic sensors for vehicle parking [online]. [cit. 2017-07-
27] Available at: http://www.newelectronics.co.uk/electronics-technology/an-
introduction-to-ultrasonic-sensors-for-vehicle-parking/24966/
[21] CarMaker [online]. [cit. 2017-07-28] Available at: https://ipg-
automotive.com/products-services/simulation-software/carmaker
[22] DRIVE REVIEW: AUDI A4 (2015) [online]. [cit. 2017-07-25] Available at:
https://www.driving.co.uk/car-reviews/first-drive-review-audi-a4-2015/
[23] Smart Driving [online]. [cit. 2017-07-27] Available at:
http://smarter.st.com/smart-driving/adas/
[24] Automotive Radar – A Tale of Two Frequencies [online]. [cit. 2017-07-27]
Available at: http://blog.st.com/automotive-radar-tale-two-frequencies/
[25] Generic Architecture for Simulation of ADAS Sensors [online]. [cit. 2017-07-28]
Available at: http://ieeexplore.ieee.org/document/7226306
[26] Sensor models for Automated and Assisted Driving. IPG. Stuttgart.
Autonomous Vehicle Test & Development 2017 [cit. 2017-07-28]
[27] Probabilistic sensor models for simulation of ADAS. BASELABS. Stuttgart.
Autonomous Vehicle Test & Development 2017 [cit. 2017-07-28]
[28] Advanced RADAR Sensors Modeling for Driving Assistance Systems Testing
[online]. [cit. 2017-07-28] Available at: http://ieeexplore.ieee.org/document/7481398
[29] Modeling and validation of a new generic virtual optical sensor for ADAS
prototyping [online]. [cit. 2017-07-28] Available at:
http://ieeexplore.ieee.org/abstract/document/6232260
[30] Sensor Models for Virtual ADAS Sensors [online]. [cit. 2017-07-28] Available at:
https://www.baselabs.de/sensor-models-for-a-more-realistic-simulation/#c-157
[31] Lane departure warning system [online]. [cit. 2017-08-14] Available at:
https://en.wikipedia.org/wiki/Lane_departure_warning_system
75
[32] FMCW Radar in Automotive Applications [online]. [cit. 2017-08-14] Available
at: https://www.cst.com/~/media/cst/landing-
pages/2016automotive/understanding--testing-fmcw-automotive-radar-
devices.ashx?la=en
[33] Automotive Simulation Models [online]. [cit. 2017-08-14] Available at:
https://www.dspace.com/en/inc/home/products/sw/automotive_simulation_
models.cfm
[34] CarSim [online]. [cit. 2017-08-14] Available at:
https://en.wikipedia.org/wiki/CarSim
[35] CarSim Mechanical Simulator [online]. [cit. 2017-08-14] Available at:
https://www.carsim.com/products/carsim/index.php
[36] Human Factors and Economic Aspects on Safety [online]. [cit. 2017-08-14]
Available at:
http://www.humanfactorsnetwork.se/Publications/Proceedings2006.pdf
[37] Driver Assistance Systems with focus on Automatic Emergency Brake
[online]. [cit. 2017-08-14] Available at: https://www.diva-
portal.org/smash/get/diva2:618217/FULLTEXT01.pdf

76
CD content
• Simulated TestRuns

• Car models

• Parametrization

• GPS output results

• Electronic version of Diploma Thesis

77