Proof of Concept of Closed Loop Re-Simulation (CLR) Methods in Verification of Autonomous Vehicles

Proof of Concept of Closed Loop Re-Simulation (CLR) Methods in Verification of Autonomous

Vehicles

MELIH GULDOGUS

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING

Proof of Concept of Closed Loop Re-Simulation (CLR) Methods in Verification of Autonomous

Vehicles

KTH School of Electrical Engineering (EES)

Degree Project in Automatic Control in collaboration with Volvo Cars

MELIH GULDOGUS

Master’s Thesis Supervisor: Siddhant Gupta

Examiner: Bo Wahlberg Stockholm, Sweden 2017

Academic dissertation with permission from the KTH Royal Institute of Technology, presented a public examination for graduation of M.Sc. in Systems, Control and Robotics on Friday 9 June 2017 at 13.15 in Automatic Control Department, KTH Royal Institute of Technology, Osquldasväg 10, Stockholm.

TRITA-EE 2017:-071 • ISSN 1653-5146

re-simulation (CLR) methods can provide a safety proof for the autonomous driving (AD) functions based on previously collected driving data. The ele- ments under study for this closed loop approach are model-in-loop based Sim- ulation Platform Active Safety (SPAS) environment and Active Safety (AS) software.

The prerequisites for securing the closed loop re-simulation environment are performing open-loop simulations with AS software under test and preparing a validated vehicle model constituting the sensors and actuators. The validated vehicle model against a set of physical data ensures high confidence in the CAE environment. This results in high correlation between physical and simulated data for the closed loop tests performed for testing the Active Safety algorithms.

This thesis work focuses on preparing the vehicle model in SPAS with the em- phasis on performance of auto-brake functionality in CLR. The vehicle model in SPAS was prepared by tuning the brake model focusing on the EuNCAP cases in which CLR environment was subsequently tested with respect to Eu- NCAP scenarios.

In the procedure of securing CLR methods, it was crucial to design the scenar- ios in virtual test environment as close as possible to field test conditions to make reliable comparison with the reality. Therefore, the verification of CLR environment was carried out by subjecting the CAE Environment to EuNCAP braking scenarios with dry surfaces, host vehicle velocities up to 80 km/h and target vehicle deceleration levels being 2m/s² and 6m/s².

As a result of all these virtual tests, it was empirically verified that CLR en- vironment can be used to predict braking behaviour of the vehicle in certain traffic scenarios for the verification of autonomous driving functions.

TRITA-EE 2017:-071 • ISSN 1653-5146

Sammanfattning

I detta examensarbete, som utförs på Volvo Cars, undersöks hurvida ett closed- loop re-simuleringsverktyg kan användas för att bevisa att en självkörande (AD) funktionalitet är säker baserat på tidigare insamlad kördata. Denna studie involverar användandet av ett Model-in-the-loop baserat simuleringsverk- tyg kallat Simulation Platform for Active Safety (SPAS) och en mjukvara för Aktiv Säkerhet (AS).

Förutsättningarna för att säkra en closed-loop re-simuleringsmiljö är att mjuk- varans exekvering och fordonsmodellen i simuleringsmiljön valideras genom open-loop tester. Den valididerade fordonsmodellen jämförs med data från fysiska prover för att säkra hög konfidens i simuleringarna.

Detta examensarbete fokuserar på att förbereda fordonsmodellen i SPAS med tryck på prestandan av auto-broms systemet. Fordonsmodellen i SPAS beredes genom att ställa in bromsmodellen med fokus på EuNCAP lastfall där CLR miljön skulle tillämpas. I processen att säkra CLR metoden var det viktigt att designa testfall i den virtuella miljön som så bra som möjligt matcha fältprovs fall för att kunna göra en trovärdig jämförelse, därav användes EuNCAP broms testfall vid torrt underlag, ego hastighet upp mot 80km/h och målbilshasdec- celeration mellan 2 m/s² och 6 m/s²

Som ett resultat av dessa virtuella test har det empiriskt verifierat att CLR metoden kan användas för att förutspå broms prestanda av fordonet i specifika trafikscenarion för självkörande funktionalitet.

TRITA-EE 2017:-071 • ISSN 1653-5146

Acknowledgements

I would like to thank every one in Driver Assistance and Active Safety CAE group (94415) at Volvo Carsp for their support throughout the project. I have had a great time, and met with remarkable people, while carrying out my mas- ter thesis project in Volvo Cars.

A special thank to:

Mert Guldogus (brother), Neslihan Guldogus (mother) and Fuat Guldo- gus (father), for motivating and inspiring me to start my journey with Master’s studies in Sweden, along with their invaluable support and advice.

Jingxiong Liu (thesis project partner from Chalmers University of Technol- ogy) for his great effort and collaboration.

Siddhant Gupta (supervisor from Volvo Cars) for his supervision, along with providing me a wonderful insight about the work and being a great mentor throughout the project.

Yury Tarakanov (group manager from Volvo Cars) for giving me this op- portunity, welcoming me in 94415 Active Safety group and supporting me in terms of many aspects.

Fredrik Bjorkqvist (colleague from Volvo Cars) for giving me great tech- nical support and helping me to write "Sammanfattning".

Bo Wahlberg (examiner from KTH Royal Institute of Technology) for pro- viding me support throughout the project and keeping me within the confines of KTH master degree project requirements.

TRITA-EE 2017:-071 • ISSN 1653-5146

Contents

Contents vii

Glossary ix

1 Introduction 1

1.1 Background . . . 2

1.2 Problem Description . . . 3

1.3 Thesis Objective . . . 3

1.4 Tools . . . 3

1.4.1 Simulation Platform for Active Safety (SPAS) Model . . . 3

1.4.2 Active Safety (AS) Software . . . 3

1.5 Methodology . . . 4

2 Open-Loop Re-Simulation with AS software 7 2.1 Implementation of Open Loop Re-Simulation with AS software . . . 7

2.1.1 Re-Simulation approach . . . 8

2.1.2 Technical flow of Re-Simulation . . . 8

2.2 Conclusion . . . 9

3 Preparation of the vehicle model in SPAS 11 3.1 Implementation . . . 12

3.1.1 The working principle of SPAS brake model . . . 12

3.1.2 Brake controller design . . . 13

3.1.3 Asynchronous test avoidance . . . 13

3.2 Results . . . 14

3.2.1 Braking Performance with Maximum Braking Request . . . 14

3.2.2 Braking Performance with Different Braking Requests . . . 21

3.3 Conclusion . . . 24

4 Closed Loop Re-Simulation (CLR) with Smart Active Safety Functions 27 4.1 Implementation . . . 28

4.2 Advanced Driving Assistance Systems - Collision Avoidance Functions . . . 28

4.3 Active Safety Emergency Braking in Volvo Car Group . . . 29

4.4 Results . . . 29

4.5 Conclusion . . . 32

5 Future Work 33

Bibliography 37

vii

Glossary

AD- Autonomous Driving

ADAS- Advanced Driver Assistance Systems AEB- Automatic Emergency Braking AS- Active Safety

CLR- Closed-Loop Re-simulation FCW- Forward Collision Warning HIL- Hardware-In-Loop

MIL- Model-In-Loop Re-Sim- Resimulation SIL- Software-In-Loop

SPAS- Simulation Platform for Active Safety

ix

Chapter 1

Introduction

The degree project is carried out in Volvo Car Group; a globally known Swedish luxury vehicle manufacturer, putting effort on the development of active safety and autonomous driving (AD) systems for around a decade. Having reliable AD systems requires engineers to put a prior effort on Advanced Driver Assistance Systems (ADAS) to experience the smooth transition towards complete autonomous driving. ADAS provides the variety of functionality to the driver to enhance the quality of driving in a safer way. These systems are commonly able to measure the alertness of the driver, along with driver’s corresponding reaction to the situation, and hence assist them to stay safe or have more proper driving.

Such systems include several active safety functions, such as adaptive cruise control, auto- matic braking and lane keeping assistant for better and safer driving. Volvo Cars focuses on the development of Autonomous Driving functionality by increasing the scope of such Active Safety functions in various situations of driving. This degree project focuses on the auto-brake functionality in specific scenarios.

Active safety functions are tested based on existing field data, whereas, it is certain that many potential traffic scenarios cannot be encountered in real traffic during the testing procedure. Only a limited number of kilometers can be tested in these field tests due to the limitations on the number of test vehicles and availability of test engineers. Moreover, the factors of cost and additional time in the product development cycle cannot be neglected.

Thus it becomes vital to compliment physical testing with virtual testing. [3]. Designing scenarios in a virtual environment can enable engineers to perform thousands of tests in computers provided that these scenarios are as comprehensive as possible within the confines of the accuracy. Additionally, the virtual assessment of those systems enables engineers to develop a systematic methodology for determining such specifications; for instance, finding an optimal operating point for one of the active safety functions with respect to an appro- priate safety metric, along with sensitivity analysis [1]. All these efforts would result in having considerably more reliable autonomous vehicles, tested with high number of distinct potential traffic situations, along with reduction of the number of not so eco-friendly field tests, fuel consumption and completely eliminating driver faults.

The virtual environment in this thesis project is the Closed Loop Re-Simulation (CLR) environment in which the complete virtual vehicle testing is conducted properly by imi- tating field tests in closed-loop virtually. This environment consists of modeling of critical elements from the field test, including vehicle dynamics, sensor and actuator models, active

1

safety functions, and other traffic elements such as roads, scenario information and sur- roundings. The successful application of CLR environment is expected to be quite valuable since this could lead engineers to perform tests in verified simulation environments rather than performing excessive amount of field tests.

1.1 Background

The big challenge for autonomous vehicles, and their verification, is that the vehicle must handle all possible traffic situations. This is in sharp contrast to traditional active safety system which focus on a specific and very limited set of critical traffic situations. In this regard, the capability of autonomous driving cars to handle all traffic situations and its verification is a big challenge.

Verification of active safety and autonomous vehicle functions requires collection of a suffi- ciently large set of data from real traffic to be able to argue statistically that the function is safe in all relevant traffic situations. In case of active safety systems, this set is large; and for the case of autonomous vehicles, it is well known to become unfeasibly large with existing methods. Therefore, the safety performance of driver assistance functions should clearly be identified with the help of sensors, computers and communication technologies for potential hazardous situations [10]. Several trade-offs are also faced by engineers in this regard such as developing heavier crumple zones in vehicle to make them safer which results in higher fuel consumption and lower brake efficiency [9]. A virtual experiment, implemented with a single scenario, provides the quantification of the effectiveness of a function where the over- all safety performance of such function is calculated with respect to observed effectiveness level weighted by the frequency of the scenario [1].

In the evaluation of safety performance, it may also be necessary to define the level of objective danger compared to potential appropriate reaction of the system [2]. Apart from the benefits of active safety systems, there exists plenty of risks due to potential flaws of imitating real environment including objects, traffic flow, roads and stochastic models of drivers which may cause false-negative and false-positive responses in the active safety sys- tem [11]. For example, they can reduce the driver acceptance of active safety systems"

[4, 5, 6]. Nevertheless, the bright side of encountering such problems in virtual designs would be a huge advantage in terms of evaluating the safety performance which can be pre- vented in advance. Considering this, CLR method, envisioned to verify the AD functions on existing field test data, is planned to be developed in a trustworthy way.

In this thesis work, the focus is on the verification analysis in the functionality of auto- brake system in CLR environment. During this analysis, it is assumed that sensors are ideal which enables to conduct virtual test drives only on functional level. Therefore, the stochastic characteristics of the sensors should always be in the state of continuous im- provement since they can always cause problems on detecting and tracking the objects which implies that the virtual test of ADAS can be associated with the quality of engineers’

underlying knowledge [1]. In other words, cautious use of virtual designs with the emphasis on ADAS can provide a high level of evidence for traffic safety assessment [7, 8].

Additional issue which needs to be addressed is that automated vehicles have a capability to change the interaction between conventional vehicles and traffic stream and influence

1.2. PROBLEM DESCRIPTION 3

the probability of conflicts and accidents [1]. This implies that, in order to create a high fidelity simulation environment for automated vehicles, the behaviour models for humans, the model for the vehicle under test, the sensor model perceiving the environment and the behaviour models for other road participants pose a strong argument in order to perform these complex simulations [3].

1.2 Problem Description

Open loop re-simulation methods cannot sufficiently validate the autonomous driving cars on a full vehicle level, since AD functions continuously control the vehicle motion, thus actively choosing what traffic situation to get involved in. Consequently, there is a need to utilize closed-loop re-simulation (CLR) methods which enable verification of new AD functions on existing field test data. These methods will use this existing data to reconstruct traffic situations in a dynamic simulation environment. The aim is to verify the performance of simulations in the dynamic CAE environment against the relevant field test data.

1.3 Thesis Objective

The thesis aims at securing the application of CLR environment with a satisfactory confi- dence level. This is carried out by verifying the auto-brake function virtually and making sure any changes in the software or tools related to this function can be verified in the same virtual environment without the need of additional field tests.Consequently, the research questions to be answered are:

• Investigating whether CLR can provide the safety proof for the AD functions based on previous driving data

• Investigating requirements on CLR tool in terms of accuracy of models (sensors &

actuators) and restoration of real traffic environment

1.4 Tools

The elements of intended CLR environment are Simulation Platform Active Safety (SPAS) model and Active Safety (AS) software. For securing the CLR environment, it is critical to validate these systems with an open loop approach which is elaborated in the next sections.

1.4.1 Simulation Platform for Active Safety (SPAS) Model

SPAS is a Matlab/Simulink based platform which enables engineers to make virtual test drives in challenging traffic situations. The SPAS environment consists of models for driver, power-plant, transmission, drive-line, chassis, brakes, steering and the electrical systems of the vehicle, along with models for other traffic elements, such as ideal/non-ideal sensors for objects, roads and signs. The SPAS environment is illustrated below in Figure 1.1.

1.4.2 Active Safety (AS) Software

AS is a software which consists of sensor fusion and the logic of active safety functions. The software creates responses based on acquired vehicle states and provides next desired states

Figure 1.1: SPAS environment

of the vehicle based on its functionality. The integration of AS software with the traffic simulation environment, SPAS, enables the closed loop virtual testing of Driver Assistance and Active Safety function testing. This integration of SPAS and AS Software constitutes the CLR application. The AS environment is illustrated below in Figure 1.2.

Figure 1.2: AS Test Environment

1.5 Methodology

As mentioned before, to secure the CLR application, open-loop validation of tools is vital which are subsequently used in the closed-loop approach. This is to ensure that limitations and potential bugs are identified in the open loop approach before they are applied in the closed-loop environment.

For the open-loop validation of both SPAS environment and AS software, a variety of field test data are used which are termed as test logs or logs. In the procedure of collecting these logs, the human driver is subjected to the real world in the test vehicle. Based on the particular test conducted, the log extracts information from various sensors and actuators of the vehicle. In this scenario, the driver can also be assisted by an Active Safety function, partially or fully. Additionally, the driver could be assisted by an ADAS or partial automa- tion. All of these logs consist of vehicle and scenario data where the scenario information is required to initiate both open-loop AS software validation and SPAS model verification analysis.

1.5. METHODOLOGY 5

In the process of validating AS software, logs with braking including normal driving scenar- ios and AD scenarios are analyzed with the emphasis on parameters influencing the braking performance. This procedure is called re-simulation (Re-Sim or Re-Play) of predefined logs with AS software in open-loop, illustrated below in Figure 1.3.

Figure 1.3: Open-Loop Re-Sim Test Environment with AS

The output of simulations is compared with test logs to validate the AS software tool, along with defining its limitations under certain scenarios. Having problematic cases in open-loop effort gives an insight about how AD functions can be developed to overcome such cases while determining the limitations of these functions in given certain scenarios.

In the process of preparing the core vehicle model in SPAS environment for open-loop tests, some of the log parameters which have effects on braking performance are given as inputs to the system under test, along with providing certain scenario information. This part is the most crucial stage of this thesis work, since the verification of SPAS environment highly implies the verification of CLR concept.

For the scope of this thesis work, the open loop validation of AS software is less criti- cal considering the modeling of the sensors being ideal. The illustration of preparing the vehicle model in SPAS for its open-loop validation is given in Figure 1.4.

Figure 1.4: Open-Loop SPAS Re-Play Test Environment

The validation of both tools under given open-loop test environments assists in securing the CLR attempts to evaluate the outputs in closed-loop system. Here, AS software including active safety functions are connected to SPAS model where the full auto-brake function is tested and validated under certain scenarios and conditions. Therefore, the prior prepara- tion of the vehicle model in SPAS with the emphasis on braking, gives an opportunity to understand how well the active safety braking function is performing in this method.

The CLR results are compared with the field test data to determine what kind of sce- narios under which conditions can actively be used in an AD car. The illustration of the CLR approach is given in Figure 1.5.

Figure 1.5: Closed-Loop Re-Sim Test Environment

The verification of CLR with this methodology helps in achieving high confidence in virtual testing of auto-braking function and hence leading in reduction of additional tests. This also ensures the development of a CAE environment which can be used to evaluate the performance of future autonomous vehicles in a secure way.

Chapter 2

Open-Loop Re-Simulation with AS software

As mentioned in the previous section, one of the prior works for CLR is to validate the AS software in open-loop and determine the limitations of the tool. Since the objective is to verify the auto-brake function under given scenarios and conditions, the focus is on the parameters which have effects on braking performance. According to the traditional model-based-development process in a software oriented industry, the software-in-loop (SIL) testing for open loop verification of the software is a crucial process to determine the ap- plicability and quality of the software. Based on the V-loop methodology [22], the SIL verification is necessary before implementation on the hardware core which is subsequently verified in hardware-in-loop (HIL) test benche(s). With the same design verification meth- ods implemented on SIL and HIL tool chain, the quality of the software can be evaluated before applying it on the actual vehicle (physical test).

The chapter focuses on the methodology implemented for the open loop re-simulation on the AS software. For the model based testing of the Active Safety Functions at Volvo Cars, the re-simulation process is essential to evaluate the errors or potential bugs in the soft- ware. With the uniformity maintained in the sensor software while executing the re-sim process on various versions of the Active Safety software, continuous development ensures the software efficiency both at the sensor and function level. This also gives an indication on the use-cases or scenarios, which are potentially error prone with respect to the function performance and hence they can be tested in the physical environment with greater impor- tance for consequent software releases.

The following sections will elaborate the implementation of open-loop re-simulation on the AS function software and the conclusions on the corresponding study.

2.1 Implementation of Open Loop Re-Simulation with AS software

The implementation of the Active Safety re-simulation test environment incorporates the open loop tests on the AS software, as illustrated in Figure 2.1.

7

Figure 2.1: Open-Loop AS Re-Sim Test Environment

2.1.1 Re-Simulation approach

The purpose of development of the re-sim tool is to re-produce the physical test log in a virtual environment with the same software implemented in the actual vehicle used in the physical test. The implementation of this re-sim tool constitutes both sensors and functions under test which are respectively termed as SENSOR stage and FUNCTION stage as given in Figure 2.2.

To ensure that the functional aspect of the Active Safety functions were under test, it was essential to keep the sub-version of the software for the SENSOR stage same while varying the sub-versions of the function software to determine the quality of the re-sim tool.

2.1.2 Technical flow of Re-Simulation

The illustration of the complete flow of AS Re-Sim application is given in Figure 2.2.

SENSOR Stage:

In the flow of AS Re-Sim application, the radar and the camera information (RaCam) from logs are fed into radar processing software and image processing software respectively. This is done by processing the raw data coming from both the radar and the camera which results in filtered RaCam data. The filtered data includes both radar objects and vision objects which are fed into the radar vision fusion software to synthesize the fused objects. This is referred to as the SENSOR Stage in the re-sim process

FUNCTION Stage:

Fused objects are fed into active safety functions, decision center of this re-simulation en- vironment, and hence the data obtained by function activation is obtained and stored in a new log, called re-simulated log. This is referred to as the FUNCTION stage in the re-sim process.

2.2. CONCLUSION 9

Figure 2.2: The flow of AS Re-Sim Application [20, 21]

Re-Simulated log is the reproduction of real field test by using the same sensor combi- nation as used on the actual vehicle. Various versions of these re-simulated logs can be produced by using different versions of the function sets in the function stage.

2.2 Conclusion

The conducted open-loop tests with AS software are carried out by the function verification engineers at Volvo Cars. Problems observed in verification process, such as encountering with a scenario that shows difference between the physical test log and re-simulated log, is reported to the function development team. The iteration of developing various software versions to eliminate all the possible bugs and issues with the software are carried out until the quality of software is ensured.

The software-in-loop testing of the Active Safety Function Software is analogous to tra- ditional black box testing methods [16]. With the AS software under test which includes components for sensor fusion and logic of active safety functions, the analysis was based on the functional correctness of the output in the re-simulated logs, with respect to pre- recorded log data without having prior knowledge about the internal states or dynamics of the environment. The illustration of such black box testing can be found in Figure 2.3.

This functional black-box testing with AS Re-Sim environment was a step to identify the potential errors of the software in the SIL tool chain. The study was done based on error prone functions or deviations from the desired output caused by deviation in desired perfor- mance of such functions. In addition, this method would also give the potential limitations of the system with the AS software not tuned for a particular set of use cases. Limitations stemming from having performance in certain use cases or failure insertion in black box testing, is also considered as a defect caused in those particular test specifications or sce- narios [16]. Considering the limitations of AS re-sim environment, this black-box testing technique was implemented with pre-recorded log data for a braking scenario data as input

to the system.

Figure 2.3: Black box Testing with AS software

Replicating SIL tests virtually enables engineers to test software on a large data set for the verification of its correctness and its quality under as many scenarios as possible. Since the re-simulated logs and corresponding test logs were identical within the range of braking scenarios tested in this project, it was fair to say that the used AS software version had no limitation for the intended experiments. This gives a quite good insight about the usability of this tool in the final stage of this work which is closed-loop-re-simulation application.

The performance of the AS Software in this study was ensured for and narrowed down to the braking scenarios. But this is not applicable to the wide array of the scenarios the software can be subjected to in the real field test. Hence the CLR application is restricted to the same braking scenarios which constitutes as the limitation of in this study. However, the open-loop black box testing with AS software showed that there is no limitation of this tool for the braking scenarios analyzed in this project.

Chapter 3

Preparation of the vehicle model in SPAS

The preparation of the vehicle model in SPAS environment is a pre-requisite to secure the CLR environment. Since the scope of this project is to perform verification analysis at func- tional level, the open loop validation of vehicle model is critical to ensure high correlation in CLR environment.

In the process of preparing the vehicle model in SPAS, sub-vehicle models or plants and controllers were analyzed, re-worked and validated based on conducted virtual tests. Since the main goal of this work is to verify the auto-brake function with CLR environment, the focus is on the models and controllers which have effects on braking performance. In the validation procedure, the vital part is to be able to repeat the open-loop field tests in virtual environments by keeping real vehicle parameters and the behavior of surroundings as close as possible to real ones.

The data-set used for the preparation and validation of the vehicle model comprised of more than 100 logs collected for testing the open loop braking performance of the physical vehicle. The logs from this data set were reconstructed in the virtual environment (SPAS) to validate the performance of the controller and plant models by comparing the simulated data to physical data-set. Accurate reconstruction of the physical logs to virtual logs en- sured high correlation and verification setup.

The discrepancy between the simulated log and virtual log can be a cause of discrepancy in the modelling of one or more subsystems in a vehicle. For example, on analyzing the acceleration performance of a vehicle from a simulated log against a physical log, the dis- crepancy can be a result of modelling performance of both the chassis and brake subsystems of a virtual vehicle. Considering this, in this study, the scenarios are designed in such a way that the performance of the virtual vehicle is only affected by the potential discrepancies in the brake plant or the brake controller. Similar process of validation can also be done for evaluating the steering performance of the vehicle. It is important to emphasize here that the preparation and validation of the vehicle model in the virtual environment should be carried out by isolating these physical subsystems. The following chapters will elaborate the preparation of the vehicle model in SPAS focusing on the brake sub-system.

11

3.1 Implementation

Preparing the vehicle model for validation against physical test data is an open-loop test with SPAS virtual environment as the system-under-test. The reconstructed log is fed as an input to the vehicle model in SPAS as illustrated below in Figure 3.1.

Figure 3.1: Open-Loop SPAS Re-Play Test Environment

3.1.1 The working principle of SPAS brake model

The brake model in SPAS includes subsystems for the Brake Controller and the Brake Plant.

The brake controller takes inputs from both the driver request on the brake pedal and the braking request from the Active Safety Software. In this open loop-study, the open loop deceleration requests from the physical test logs are fed to the brake controller as shown in Figure 3.1.

Figure 3.2: The working principle of SPAS Brake Model

Brake controller works with the principle of controlling the error between the desired open loop braking request and the instantaneous deceleration of the vehicle as a feedback. The control effort is calculated as the pressure rise in the master cylinder which is ultimately converted to the brake torque on the wheels. This constitutes the model of the brake plant as shown in Figure 3.2.

The chassis of the virtual vehicle in SPAS is modelled with 7 degrees of freedom. The

3.1. IMPLEMENTATION 13

various degrees of freedom are wheel rotations on respective axes, translation of the vehicle in lateral and longitudinal direction and yaw angle of the vehicle. Moreover, the longitudinal brake dynamics which is very important for this study in terms of evaluating the auto-brake effort in CLR and to provide proof of safety, is also affected by tyre model in SPAS. The tire model is based on the Pacjeka model [17] which provides the tire forces in the x,y and z direction along with the moment around the z-axis. Since the physical test-data does not provide the tire forces, the study focused on validating the chassis and brake model in for evaluating the braking performance.

Hence for the validation of the vehicle model for the braking scenarios, the evaluation of brake controller is important to ensure good correlation between virtual test runs and physical test runs.

3.1.2 Brake controller design

The brake controller under study was initially developed for virtual analysis of emergency braking scenarios which require heavy deceleration. This lead to the control effort being overestimated even for braking requests which required moderate deceleration levels. Also, to model the driver braking performance, it is essential to tune the controller suitable for all deceleration levels in order to simulate a diverse set of use cases with low to moderate deceleration levels which are usually encountered during city driving.

The objective of the controller is to also suit the verification of the autonomous driving scenarios, which will include deceleration levels from low to moderate to high. Since the scope of this thesis work is to verify the auto-brake function under given scenarios, along with the proof of this active safety function, a robust PI controller was designed with various tests conducted with different potential deceleration request information that the vehicle can take in the road.

In the procedure of tuning this PI controller, step requests varying between 4 m/s² and 12 m/s² were fed into the SPAS environment in open-loop and the PI controller gains were optimized with respect to the braking performance observed in virtual logs obtained from SPAS. The results are elaborated at the end of this chapter.

3.1.3 Asynchronous test avoidance

The verification was handled by observing the difference between physical test logs and virtual test results. The differences in the setup of the physical test environment and the virtual test environment can lead to potential synchronization problems when comparing this physical and virtual test data.

The first issue in the validation procedure of prepared SPAS vehicle model can be asso- ciated with the delay and reaction times of hardware components. For instance, in the case of emergency braking, the object detection by sensor, the pressure build up in the master cylinder and the control effort provided by the braking system, all include a phys- ical delay in the system. It is important to model these delays in the virtual environment too. In this regard, a delay was modelled in SPAS environment, illustrated below in Figure 3.3, with respect to the tests, which enable to understand the overall reaction time of real components.

Figure 3.3: Synchronization of Log and SPAS Results

The second issue was related to the sampling rate difference between logs and SPAS results.

Logs, used in this project, had sampling period of either 0.2 s (second) or 0.25 s; whereas the sampling period of SPAS environment was 0.001 s. To overcome this problem, down- sampling operation was simply implemented on SPAS results. The results with avoided potential synchronization problems are given in the next section in detail.

3.2 Results

The scope of this project is to evaluate the auto-brake effort of the vehicle with the em- phasis on collision avoidance in a closed loop virtual environment. The maximum brake request is needed from the auto-brake function to avoid the collision in dangerous situa- tions. Therefore, several open-loop field tests were conducted with deceleration requests of suitable ranges, and the verification of auto-brake function was performed with respect to determining the adequate value of deceleration as well.

The existing brake controller was tuned with respect to 12 m/s² previously, whereas, it was re-tuned [15] with different deceleration request information to validate the auto brake effort for more use-cases. Consequently, the field tests, conducted with deceleration requests of other values were also used to validate the auto brake effort. Most of the scenarios verified in this study were with 12 m/s²due to the abundance of data with that particular request.

3.2.1 Braking Performance with Maximum Braking Request

These open-loop tests with maximum braking requests were conducted with a host vehicle on a straight road. 12 m/s² braking request was fed into the SPAS environment in open- loop where the host vehicle has constant speed. The virtual tests were implemented when the velocity interval of the host vehicle was from 10 km/h (kilometer per hour) up to 80 km/h. The number of logs used for this comparison for each scenario changes between 5 to

3.2. RESULTS 15

7, in which more than 100 logs were used for the analysis of selected scenarios in this thesis project where Volvo XC60 and Volvo S90 models were used.

In the figures below, the blue color indicates the step deceleration request which is al- ways 12 m/s²in this particular test cases. Red and black colors correspond to deceleration of the vehicle from the real log and SPAS, respectively. In addition, the pink color repre- sents the velocity of the vehicle from the log, where the light blue color is for the velocity information from SPAS.

The sections which were analyzed in these figures start from the beginning until the ve- locity becomes zero. The remaining part consists of various oscillations stemming from the internal dynamics of the tyres which was ignored in this study. Unsurprisingly, there is no need to analyze the system after the velocity of host car becomes zero.

In the case of vehicle traveling at 10 km/h, the deceleration request of 12 m/s² causes the vehicle to come to a complete halt before the vehicle reaches the requested level of deceleration as shown in Figure 3.4.

XC60

XC60 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (10 km/h)

Figure 3.4: Maximum Braking Request when the host vehicle drives with 10 km/h

XC60 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (20 km/h)

Figure 3.5: Maximum Braking Request when the host vehicle drives with 20 km/h

XC60 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (30 km/h)

Figure 3.6: Maximum Braking Request when the host vehicle drives with 30 km/h

3.2. RESULTS 17

XC60 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (40 km/h)

Figure 3.7: Maximum Braking Request when the host vehicle drives with 40 km/h

XC60 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (50 km/h)

Figure 3.8: Maximum Braking Request when the host vehicle drives with 50 km/h

XC60 Open-Loop Braking Distances

The performance analysis of auto-brake function in open-loop, was done by calculating the braking distances of the vehicle in SPAS and comparing this with the corresponding braking distance information stored in real field tests. In figures, blue bars represent the average braking distances of the vehicle from the field tests under given scenarios, whereas the red bars represent the braking distance from the SPAS environment. The difference in the braking distance between the SPAS environment and the real logs can also be observed in Figure 3.9.

The braking distance of the vehicle was found by calculating the area under the velocity curves in both physical test logs and SPAS. In this procedure, the calculation was initiated from the beginning until the velocity becomes zero. The remaining part was not included in braking distance calculation.

As it is clearly seen in Figure 3.9, the vehicle stops with less amount of braking distances in SPAS environment by favorably staying very close to the corresponding braking distance information from the logs. Specifically, it was shown that the vehicle stops earlier in SPAS environment with approximately 15 cm, 15 cm, 40 cm, 70 cm and 80 cm for 10 km/h, 20 km/h, 30 km/h, 40 km/h and 50 km/h scenarios, respectively. The gap between braking distances increases as long as the vehicle velocity increases as expected since higher velocity would naturally cause higher deviations during braking effort. Nevertheless, it is essential to indicate that the proportional difference in braking distances is almost same in every scenario.

Figure 3.9: XC60 Open-Loop Braking Distances under different speed

3.2. RESULTS 19

S90

S90 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (30 km/h)

Figure 3.10: Maximum Braking Request when the host vehicle drives with 30 km/h

S90 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (50 km/h)

Figure 3.11: Maximum Braking Request when the host vehicle drives with 50 km/h

The same auto-brake function shows very similar characteristics in S90. In addition to XC60, this also includes a test with 70 km/h where the auto-brake function shows its best performance, as illustrated in Figure 3.12.

S90 - Deceleration Request (12 m/s²) with Host Vehicle Velocity (70 km/h)

Figure 3.12: Maximum Braking Request when the host vehicle drives with 70 km/h

S90 Open-Loop Braking Distances under Maximum Braking Request

Figure 3.13: S90 Open-Loop Braking Distances with maximum braking request

As it can clearly be seen from Figure 3.13, the vehicle in SPAS environment stops also with less amount of braking distance in Volvo S90. In addition, the trend in both XC60 and S90

3.2. RESULTS 21

indicates that the deceleration dynamics of SPAS results are closer to the real ones when the velocity is higher.

3.2.2 Braking Performance with Different Braking Requests

These open-loop tests were conducted with 4 m/s², 6 m/s² and 8 m/s² deceleration re- quest, along with the comparisons with more than 40 logs. The main purpose is to be able to validate the SPAS model by using different deceleration requests rather than the max- imum braking request. As indicated above, the validation of this environment with such cases increases the potential use of auto-brake function in variety of scenarios. Available field tests with lower deceleration request include the scenarios with mostly 70 km/h and with only one vehicle, S90. Some of these open-loop results are demonstrated below in detail.

SPAS environment was also tested with scenarios with higher velocities starting from 100 km/h up to 200 km/h. However, the insufficient amount of field tests for these scenarios makes the comparison between the SPAS results and logs unfavourable and hence these scenarios had to be excluded from the scope which are the limitations of this thesis work.

S90

S90 - Deceleration Request (4 m/s²) with Host Vehicle Velocity (70 km/h)

Figure 3.14: 4 m/s

²

Braking Request when the host vehicle drives with 70 km/h

S90 - Deceleration Request (6 m/s²) with Host Vehicle Velocity (70 km/h)

Figure 3.15: 6 m/s

²

Braking Request when the host vehicle drives with 70 km/h

S90 - Deceleration Request (8 m/s²) with Host Vehicle Velocity (70 km/h)

Figure 3.16: 8 m/s

²

Braking Request when the host vehicle drives with 70 km/h

3.2. RESULTS 23

S90 Open-Loop Braking Distances under different Braking Requests

Figure 3.17: S90 Open-Loop Braking Distances with different braking requests

As seen in Figure 3.17 above, regarding braking performance analysis with S90, SPAS results have slightly larger braking distances than logs unlike previous tests which were conducted with maximum braking request. Due to the potential unfavorable initializa- tion of several sub-components in SPAS and synchronization issues for scenarios without maximum braking request, some unfavorable peaks occurred periodically in deceleration dynamics in such scenarios, as illustrated in Figure 3.14, Figure 3.15 and Figure 3.16.

The synergies between the dynamics of the sub-components of the SPAS environment like the brake model, the tire model and the chassis model made it challenging to evaluate and isolate the behaviour of these peaks. It could also be interpreted that slightly larger braking distances are caused by these peaks in deceleration causing periodic oscillations.

Besides, in the case where 8 m/s² deceleration request is fed into the system, there is an unexpected behavior of SPAS deceleration. This behavior can easily be seen in Figure 3.16 where the deceleration drops unfavorably. Although, there exists the deceleration drop and the peaks in some use-cases mentioned above, the braking distance performance shows that the auto-brake function works almost same as it is in the real car and the host vehicle stops in a fairly well distance.

Specifically, the braking distances in SPAS is higher than logs with around 1.8 m, 0.9 mand 0.3 m where the deceleration requests are 4 m/s², 6 m/s² and 8 m/s² respectively with 70 km/h host vehicle velocity. This is reasonable since increasing the deceleration request decreases the braking distance of the vehicle. Admitting that most of braking dis- tance differences between logs and SPAS results stems from the unfavorable peaks, can be referred to the fact that the auto-brake effort under different deceleration request can even be more accurate than observed in results.

The interesting observation was the absence of such peaks in CLR application which was a triggering effect about spending no more time on reasoning of these mysterious peaks in open-loop; and instead focusing on CLR. In Chapter 4, the CLR application is elaborated including experimental results with multiple vehicles.

3.3 Conclusion

Having full control over all the actors in the environment in a dynamic traffic scenario helps to make adjustments so that the system is only influenced by the intended sub-models in SPAS. These adjustments result in precise model-based sensitivity analysis which provides the accuracy of the model under test and gives insight about its verification process. Con- sequently, having more accurate models leads to more reliable validation outcomes with higher confidence level.

It is possible to make various configurations with different components in SPAS including driver, power-plant, transmission, driveline, chassis, brakes, steering and also ideal/non- ideal sensors for objects, roads and signs. In the process of validating the vehicle model in SPAS, the sensors and smart active safety functions are not included in the configuration so that only core vehicle can be evaluated. In this thesis work, since the focus was only on the brake performance of the vehicle, the environment was re-configured in the way that only brake model can be evaluated and validated in core SPAS environment. The reconfiguration process was carefully completed to make the sensitivity analysis in a precise way.

The sensitivity analysis was performed in core SPAS environment to observe the scope of scenarios the brake model can be tested in. Since, at a certain level, it was possible to isolate the behaviour of sub-components being active with assigned scenarios during simu- lation, the conditions and scenarios were created and expanded step by step so that only brake model can stay active during simulation. In scenario design, since uncertainties exist in data and sub-models, it was essential to figure out the limits of such scenarios, triggering only the brake model, so that it becomes possible to observe under what kind of conditions and scenarios, the result of the system stays unchanged [12].

Creating such special configurations required few adjustments considering the architecture of the SPAS environment, along with several assumptions to stay within the confines of the project scope. The chassis model, brake model and the tire model have synergies in the functioning of the virtual vehicle modelled in SPAS environment. The 7 degree-of-freedom chassis model was assumed sufficiently good to restrict the analysis only on the brake model.

The acceleration pedal in the driver model was disabled not to create fluctuations in sub- models which have effects on acceleration or deceleration dynamics. Instead, a constant speed was assigned to the host vehicle as a specification of running scenario. Furthermore, the scenarios were only designed for straight roads since having curvy roads was activating the steering model and was requiring further analysis with steering dynamics. For the sake of simplicity, dry roads were used in these scenarios to avoid making friction analysis using tires and dealing with lateral dynamics of the vehicle.

All of these virtual experiments were conducted with automation scripts to increase the efficiency of the simulations executed and analyzed. Securing the automation process for analysis and verification scenarios which only influences brake model enabled us to analyze

3.3. CONCLUSION 25

the performance of the brake model in SPAS environment.

Since the brake plant was modelled based on physical data from brake department, the focus on this thesis work was only on the brake controller where the PI controller was de- signed accordingly. The longitudinal brake dynamics can be referred in [13].

As mentioned above, in the open-loop validation, step requests were manually fed into the brake model to see the braking performance of the vehicle. The controller was designed and its performance was evaluated based on a theory with the step response analysis on second-order systems with PI controller, along with high number of tests and tuning. It is usual to use step requests to measure controller performance to understand how well the controller behaves, along with determining the steady state error.

During PI controller design, the goal was to keep the response of such complex brake system based on the step requests or deceleration requests changing between 4-12 m/s²at reasonable level where the controller was designed based on the theory in [15]. The relia- bility of designed controller was developed in the way that guarantees reasonable stability margins, along with a good overall performance for wide variety of tests [14].

The vital aspect was to control the deceleration based on the deceleration request in the system. Therefore, tuning the PI-controller gains was essential to follow the desired decel- eration in SPAS. Since eliminating steady-state error in the system was a must for this PI controller implementation, the integral gain was very carefully tuned. Since the increase in PI-controller gains cause decrease in rise-time and increase in over-shoot, the trade-off between these two features in design process was very well adjusted. Regarding all the control effort, keeping the "P" gain is relatively higher than "I" gain resulted in intended controller effort which is suitable for wide variety of processes.

Pre-existed brake plant with respect to the principle given in [13], implementing PI con- troller based on the theory in [15], designing scenarios for brake performance with a careful sensitivity analysis and avoiding all the synchronization problems by sampling and mod- elling the reaction time of components eventually reached to a point where the preparation of the vehicle model in SPAS was completed and became ready to be used in CLR application.

Involving all the efforts indicated above, the core SPAS environment with designed brake controller was validated with respect to the comparison between logs and SPAS results in braking distances under the theory of calculating such distances by looking at velocity curves. The core XC60 and S90 vehicle models were validated for the carefully selected braking scenarios including test cases with dry roads, 4-12 m/s² deceleration request and 0-80 km/h host vehicle’s velocity.

The unfavorable problems encountered in open-loop SPAS validation was not due to the brake model and brake controller or not stemming from the potential asynchronous tests in SPAS environment.It was concluded that the peaks, detected in cases where the decelera- tion request is not 12 m/s², caused by the potential initialization of several sub-components in complex SPAS environment. Due to the absence of these peaks in closed-loop approach given in Chapter 4, further investigation about such peaks was not conducted in this thesis work.

Considering all this, the dynamics of the velocity curves in both SPAS and logs give almost the same responses in all the scenarios tested in this stage. The difference between braking distances was very close with one another in both SPAS and logs so that this was pointed out as the indication of how close the virtual environment behaves to the real logs. The results obtained in open-loop SPAS tests with satisfied confidence level shows that SPAS environment can be used in CLR application under certain scenarios.

This work is particularly important for Volvo Cars and for any other automotive companies dealing with virtual tests of hazardous situations. The effort in this chapter, showing al- most perfect correlation between real world and virtual environment with the emphasis on braking performance, is the indication of accurate brake modelling, well-tuned PI controller and successfully avoided synchronization problems for wide variety of test cases.

Having validated core SPAS environment and the successful validation of open-loop AS software tests resulted in the initiation of the main goal of the thesis project, CLR applica- tion.

Chapter 4

Closed Loop Re-Simulation (CLR) with Smart Active Safety Functions

The validation of AS software and the validated vehicle model in SPAS with the emphasis on braking under certain scenarios indicated above in Chapter 2 and Chapter 3 resulted in securing the CLR application which is the main goal of this thesis project.

Since this is a closed-loop approach, in closed-loop-resimulation, the corresponding test scenario as per the physical log is recreated by subjecting the vehicle model in closed loop with the AS software. Instead of feeding the log into AS software in open-loop and re- simulating the system to evaluate the AS software, the object and scenario information is setup in SPAS environment and scenario subsystems and simulated at every time step. In addition, instead of feeding the braking request to SPAS model in open-loop to evaluate the vehicle behavior, this braking request is fed from the AS software into the SPAS model according to the sensor information collected in previous time step. This braking request, via the brake plant is converted to braking torque on the wheels and the corresponding vehicle deceleration is fed as an updated state in closed loop.

Unlike previous open-loop validation efforts to test the sensor efficiency and the brake per- formance by studying the re-simulated sensor outputs and braking distances respectively in CLR approach, the braking distance (distance between the host and target vehicle after braking maneuver) was used as a metric. These tests in CLR enabled us to study the per- formance of the auto brake functionality embedded in the AS software.

As known from previous chapters, there is only host vehicle in open-loop tests, and hence measuring the sensor efficiency with re-simulation in computers, calculating braking distance and comparing all this with the field test results are valuable for corresponding open-loop validation efforts.

On the other hand, it is valuable to check relative distance between host and target ve- hicle in CLR and to compare this parameter with the relative distance information from the field tests. After the validation of the vehicle model in SPAS in the specific use cases, the study on CLR approach is expected to result in good correlation with the physical test data.

27

4.1 Implementation

CLR application is a closed-loop environment where SPAS vehicle model and AS software are connected in closed loop, illustrated below in Figure 4.1. The AS software sends the commands for driver assistance or collision avoidance based on the scenario the vehicle is subjected to.

Figure 4.1: Closed-Loop Re-Sim Test Environment

4.2 Advanced Driving Assistance Systems - Collision Avoidance Functions

The focus on the improving the driving assistance systems in Active Safety is paving the path for the logic of autonomous driving functions. Under a potential collision threat, the driver presses the brake pedal when he/she encounters with the dangerous situation on the road. In driver assistance systems, the auto-brake function would either help the driver if the driver braking is not sufficient or bring the vehicle to a complete halt in case the driver

4.3. ACTIVE SAFETY EMERGENCY BRAKING IN VOLVO CAR GROUP 29

is not attentive or aware of the threat and does not engage the brake. In this case, it is better for a vehicle to execute maximum braking to avoid fatal injuries. The effort in this thesis project can be interpreted as a study which is promoting the auto-brake performance in ADAS with desired collision avoidance to a more extended level for its potential use for complete autonomous vehicles which is elaborated in Chapter 5.

4.3 Active Safety Emergency Braking in Volvo Car Group

Currently Volvo Cars equipped with Active Safety system including auto-brake function or active safety emergency function, have Forward Collision Warning (FCW) and Automatic Emergency Braking (AEB) states. The vehicle detects the target on the road and activates the FCW state. If the driver presses the brake pedal, the adequacy of such braking effort is calculated by the vehicle. Based on the quality of braking applied by the driver, the Active Safety system assists the braking effort to bring the vehicle to a complete halt or avoid the collision accordingly. Naturally, having more sufficient initial driver braking leads to lesser assistance from the Active Safety system.

Figure 4.2: ADAS with emergency braking in Volvo Car Group

On the other hand, if this driver braking is not sufficient, then the vehicle goes into AEB state where the auto-brake function activates to avoid accidents. If auto-brake function is successful, the potential collision with the target is avoided; otherwise, it could cause a crash, as illustrated above in Figure 4.2.

The focus on this thesis work was on the AEB state, and hence the braking performance of auto-brake function. Available open-loop field tests in Volvo Car Group includes a lot of scenarios with maximum deceleration request (12 m/s²) and several scenarios with less deceleration request (4 - 12 m/s²). Braking performance results obtained with CLR envi- ronment based on one of the tested scenarios are given in the next sections in detail.

4.4 Results

For the accurate CLR analysis, potential synchronization problems were avoided in the same way, explained in Chapter 3. In addition to this, the field tests and CLR results were aligned with respect to their FCW states. The time instant when the FCW states are enabled during real driving and CLR environment were matched with one another so that the auto-brake function effort can be observed in AEB state around the same time step.

This enables us to calculate the relative distance between the host and target vehicle with an excellent precision.

Test cases and conditions used in CLR are the ones that were previously used in the proce- dure of open-loop validations. This includes the conditions of straight road with dry surface and the velocity interval of host vehicle between 0 km/h to 80 km/h. CLR results for one of the scenarios are given in this section in detail. This selected scenario includes two vehicles in the environment in which one of them is the host vehicle, Volvo S90, moving with 50 km/h constant speed and the static target vehicle that is on the same lane with the host vehicle. CLR results for this particular scenario are compared with the field test results conducted under same conditions and specifications with CLR environment.

The same version of validated AS software and validated SPAS environment based on the brake model were used in this CLR application. Since no limitation was detected in open- loop validations elaborated in both Chapter 2 and Chapter 3 on certain scenarios, it was expected to have no limitation also in CLR environment regarding such scenarios.

Volvo S90 tested on dry road

Host Vehicle Velocity moving with 50 km/h Static (0 km/h) Target Vehicle Velocity

Deceleration Analysis

Figure 4.3: Volvo S90 Deceleration Request and Deceleration with FCW and AEB

Flags

4.4. RESULTS 31

Volvo S90 tested on dry road

Host Vehicle Velocity moving with 50 km/h Static (0 km/h) Target Vehicle Velocity

Relative Distance Analysis

Figure 4.4: S90 Deceleration Request and Relative Distance with FCW and AEB (CMBB) Flags

As it can clearly be seen from above, the conducted test results indicate that the relative distance information observed both from the field test and CLR environment are similar and the dynamics of relative distance information are extremely close to each another. This indicates that the auto-brake function in virtual CLR environment performs satisfactorily for this specific scenario.

It is visible that the relative distance until some point has oscillations in real log which was indicated above in the figures with black color. The reason of this is the fact that CLR environment uses ideal sensors, while the real sensor experiences noise corrupted signals and uncertainties during the field test. That is to say, in Figure 4.4, the ideal sensor used in CLR shows 200 m which is the default value for the sensor when there is no object detection. This ideal sensor detects the object when the red curve made a drop around 135 m, indicated with black circle.

On the other hand, the black curve representing the real sensor has always oscillations due to such noise corrupted signals preventing accurate detection of the objects until some point which delays the real target detection. As seen from the figure, the real sensor detects the target around 125 m. After this crucial point, the relative distance between the host and the target vehicle shows similar behavior in both field test and CLR environment. Specif- ically, the host vehicle stops before 4.5 m before the target car in this particular scenario and the potential collision is avoided with the help of auto-brake effort.

Even if there are differences regarding object detection performance in real and virtual environment, aligning FCW flags enable us to make an accurate braking performance anal- ysis. It can be observed that the vehicle decelerates in both log and CLR environment at exactly the same point, AEB state, illustrated with green filled color in the figures above.

The results for other tested scenarios in this thesis work, along with the scenario details are elaborated in [18].

4.5 Conclusion

The validation of AS software and the validated vehicle model in SPAS results in successful application of CLR. The braking scenarios that can be encountered in real roads were tested and collisions were avoided completely. This thesis work shows the effectiveness of CLR environment and indicates the proof of safety of CLR environment by emphasizing the fact that virtual environment results are quite close to the field test results.

In the process of validating AS software and vehicle model in SPAS, open-loop virtual tests indicated no limitation in which having no limitation in CLR environment with exactly same scenarios were obtained as expected. Logs and Re-Simulated logs with AS software were identical. Validated vehicle model in SPAS had highest confidence in braking distance, high enough confidence in velocity and relatively less confidence in deceleration dynamics for S90 and XC60.

In the procedure of CLR application, almost 100% confidence level were obtained in relative distance information which is the most crucial parameter regarding the collision avoidance.

Chapter 5

Future Work

The vital part in this thesis work was to virtually verify the collision avoidance active safety function in certain scenarios through the usage of CLR environment and to verify the accu- racy of such virtual environment by comparing the CLR results with the field test results.

As mentioned above, this work shows the performance of auto-brake effort of the vehicle when the driver braking is inadequate. The idea, in the future, is to expand this work for verifying both comfort braking and emergency braking for autonomous driving vehicles.

Compared to collision avoidance with ADAS, the auto-brake should have much more func- tionality in a complete autonomous vehicle, since the driver is not active in this case and the vehicle should not only avoid the accidents with maximum braking when necessary, but also control all the vehicle motion by gentle braking in normal driving moments. To verify the braking capabilities and functionalities in the AD vehicle virtually, a higher fidelity vir- tual environment needs to be setup. On re-simulation environment, this can be facilitated by importing logged driving data on the AD route and re-simulating the logged data with the autonomous braking function in the validated vehicle model in SPAS environment. In addition, this was one of the main motivations why the brake controller was designed in the way that it can be adaptable to multiple deceleration request scenarios.

In the process of developing vehicles, equipped with smart active safety functions or ADAS, for the last decade in Volvo Cars, the focus was on the supervised driving, illustrated in Figure 5.1. The purpose of these smart (Active Safety) functions is to assist the driver when steering, braking or accelerating and aid the driver’s efforts in such case for particular encountered situations. These functions have been developed by learning from the drivers’

experience based on several parameters influencing the safety performance, along with the user experience, traffic flow and energy efficiency.

Today, the goal is to achieve the safe and reliable transition from supervised driving to unsupervised driving or auto-pilot. In unsupervised driving, driver is partially eliminated from driving and the corresponding functionality including steering, braking and acceler- ating is handled autonomously by the vehicle. The vision about unsupervised driving or driving a complete autonomous vehicle is illustrated in Figure 5.2.

33

Figure 5.1: Supervised Driving [19]

Figure 5.2: Unsupervised Driving [19]

35

The effort for partially unsupervised driving is currently tested in Gothenburg in Volvo Cars Drive-Me project. As a part of this project, several families and drivers have been selected by Volvo Cars to test these cars on Gothenburg Drive-Me route in Gothenburg, as illustrated in Figure 5.3, to collect data for the development of future AD cars.

Figure 5.3: Drive-Me route (AD route in Gothenburg) [19]

Considering the vision regarding AD cars, the next step should be the extension of this thesis work by adding the auto-steer functionality. This can be initiated by designing traffic scenarios requiring steering effort, such as assigning curvy roads in these scenarios which makes the steering action inevitable.

Validation of the steering characteristics of the vehicle requires a good model for the steer- ing subsystem on the virtual vehicle. Therefore, the steering plant and steering controller should be verified and improved if necessary, as it was applied to brake model in this thesis work. In this way, the number of verified scenarios for AD cars, along with their complexity level is increased. Additionally, the effectiveness of virtual environments, such as CLR, is measured by comparing simulation results with the field tests. Hence, the careful develop- ment and verification process of such work would eventually reach to a point where proof of safety of CLR environment is provided for increased number of situations.