control functions solution design - deserve project · 2014-12-03 · control functions solution...

Control functions solution design Public Copyright DESERVE

Contract N. 295364

Control functions solution design

Deliverable n. D4.2.1 - Control functions solution design

Sub Project SP 4 Test case functions

Work Package WP 4.2 Control functions

Task n. T 4.2.1 Requirement analysis and solution design

Author(s) J. Klimke et al. File name D4.2.1_Control_functions_final

Status Final

Distribution Public (PU)

Issue date December 2013 Creation date June 2013

Project start and

duration

1st of September, 2012 – 36 months


Contract N. 295364

Version 1.0 of 51

TABLE OF CONTENTS

TABLE OF CONTENTS ............................................................................................. 2

LIST OF FIGURES .................................................................................................. 4

LIST OF TABLES .................................................................................................... 4

LIST OF ABBREVIATIONS ....................................................................................... 5

ABBREVIATION ..................................................................................................... 5

DESCRIPTION ....................................................................................................... 5

ANTI-LOCK BRAKING SYSTEM ................................................................................. 5

ADAPTIVE CRUISE CONTROL .................................................................................. 5

SUB-PROJECT ....................................................................................................... 7

WORK PACKAGE .................................................................................................... 7

REVISION CHART AND HISTORY LOG ....................................................................... 8

EXECUTIVE SUMMARY ........................................................................................... 10

1. INTRODUCTION .............................................................................................. 11

2. PLATFORM DESCRIPTION ................................................................................. 12

2.1. Platform structure ................................................................................................ 12

2.2. Software ............................................................................................................. 13

2.2.1. Simulation environments ............................................................................................. 14

2.2.2. Perception and fusion development tools ....................................................................... 16

2.2.3. Digital maps ............................................................................................................... 17

2.3. Hardware ............................................................................................................ 17

3. VEHICLE EQUIPMENT ....................................................................................... 18

3.1. Data sensing ....................................................................................................... 18

3.2. Perception layer for localisation and mapping .......................................................... 19

3.3. Data management ............................................................................................... 20

3.4. Processing units ................................................................................................... 22

3.5. Actuators ............................................................................................................ 23


Contract N. 295364

Version 1.0 of 51

4. REQUIREMENTS .............................................................................................. 24

4.1. Vehicle types ....................................................................................................... 24

4.1.1. Passenger cars ........................................................................................................... 25

4.1.2. Light commercial vehicles ............................................................................................ 26

4.1.3. Trucks ....................................................................................................................... 27

4.1.4. Motorcycles ................................................................................................................ 28

4.2. Environments ...................................................................................................... 29

4.2.1. Urban ........................................................................................................................ 29

4.2.2. Inter-Urban ................................................................................................................ 32

4.2.3. Highway .................................................................................................................... 34

5. SOLUTION DESIGN FOR THE CONTROL FUNCTIONS ............................................ 38

5.1. Urban control functions ......................................................................................... 38

5.1.1. Longitudinal control ..................................................................................................... 38

5.2. Inter-urban control functions ................................................................................. 41


5.2.2. Lateral control ............................................................................................................ 44

5.3. Highway control functions ..................................................................................... 46


CONCLUSIONS ..................................................................................................... 48

REFERENCES ....................................................................................................... 50


Contract N. 295364

Version 1.0 of 51

LIST OF FIGURES

Figure 1 - DESERVE platform framework .........................................................................................................13

Figure 2 – The DESERVE platform as HiL in PELOPS .........................................................................................15

Figure 3 - Example of Full-Featured Processing Platform Zyng 7000 [13] ........................................................23

Figure 4 – Example of trucks for various services ............................................................................................27

Figure 5 - Truck-trailer combinations ..............................................................................................................28

Figure 6 - Rear to rear accidents scenarios ......................................................................................................30

Figure 7 - Pedestrian accidents in crossing scenarios without obstructed view [4] ..........................................31

Figure 8 - Pedestrian accidents in crossing scenarios with obstructed view [4] ...............................................31

Figure 9 - Pedestrian accidents in turning scenarios [4] ..................................................................................32

Figure 10 - Host vehicle approaching to a standing vehicle in the same lane ..................................................32

Figure 11 - Host vehicle approaching to a decelerating vehicle in the same lane ............................................33

Figure 12 - Lane structure scheme of a typical highway section ......................................................................36

Figure 13 - Area managed by the control algorithm ........................................................................................38

Figure 14 - Functional block diagram for AEB pedestrian (CRF demonstrator) ................................................40

Figure 15 – Safe passing vehicle ......................................................................................................................45

Figure 16 - Functional ACC Elements [6] ..........................................................................................................46

LIST OF TABLES

Table 1 – Sensors for the usage in control functions .......................................................................................20

Table 2 - Inter-urban road structure elements ................................................................................................33

Table 3 - Highway road elements ....................................................................................................................36


Contract N. 295364

Version 1.0 of 51

LIST OF ABBREVIATIONS

ABBREVIATION DESCRIPTION

ABS Anti-lock Braking System

ACC Adaptive Cruise Control

ADAS Advanced Driver Assistant System

ADASIS Advanced Driver Assistance System Interface Specification

ADTF Automotive Data and Time-triggered Framework

AEB Autonomous Emergency Braking

AEBS Advanced Emergence Braking System

APA Automatic Parking Assist

ARAS Advanced Rider Assistant System

ASIC Application-Specific Integrated Circuit

ASM Automotive Simulation Model

CAN Controller Area Network

CPU Central Processing Unit

DESERVE Development Platform for Safe and Efficient Drive

D-GPS Differential Global Positioning System

e-horizon Electronic Horizon

ECM Electronic Control Module

ECU Electronic Control Unit

ESC Electronic Stability Control

EVP Enhanced Vehicle Position

FNRP Frontal Near Range Perception

FOP Front Object Perception


Contract N. 295364

Version 1.0 of 51

FPGA Field Programmable Gate Array

GPS Global Positioning System

HDL Hardware Description Language

HW Hardware

HiL Hardware in the Loop

IEEE Institute of Electrical and Electronics Engineers

IU-ACC Inter-urban Adaptive Cruise Control

IWI Intervention-Warning-Information

LC Lane Course

LCV Light Commercial Vehicle

LIDAR Light Detection and Ranging

LKC Lane Keeping Control

MiL Model in the Loop

MRR Mid-Range Radar

(Euro) NCAP (European) New Car Assessment Programme

PC Personal Computer

PCM Powertrain Control Module

PELOPS Program for the dEvelopment of Longitudinal micrOscopic traffic Pro-

cesses in System relevant environment

PTW Powered Two Wheeler

RPR Road of the Ego Vehicle

RTK Real Time Kinematic

SAE Society of Automotive Engineers

SDK Software Development Kit

SiL Software in the Loop


Contract N. 295364

Version 1.0 of 51

SoC System on a Chip

SP Sub-Project

SW Software

TCP Transmission Control Protocol

TLC Time to Lane Crossing

TSD Traffic Sign Detector

TTC Time To Collision

UDP User Datagram Protocol

USB Universal Serial Bus

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

VRU Vulnerable Road Users

Wi-Fi Wireless Fidelity

WP Work Package


Contract N. 295364

Version 1.0 of 51

REVISION CHART AND HISTORY LOG

REV DATE AUTHOR REASON

0.1 2013/06/01 Jens Klimke (IKA) Initial version

0.2 2013/09/19 Jens Klimke, Fre-

deric Christen

(IKA)

Draft structure for initial discussion

0.3 2013/10/01 Jens Klimke (IKA) Instructions, first draft

0.4 2013/10/10 Jens Klimke, Fre-

deric Christen

(IKA)

Contribution for chapters platform structure,

Actuators, Environments (inter-urban) and in-

ter-urban control function

0.5 2013/10/14 Nereo Pallaro

(CRF)

Passenger cars, Urban and inter-urban envi-

ronments, AEB pedestrian and AEB inter-

urban control functions, Light commercial ve-

hicles

0.6 2013/10/14 Arto Kyytinen

(TTS)

Data management

0.7 2013/10/16 Arto Kyytinen

(TTS)

Motorcycles

0.8 2013/10/17 Paul van

Koningsbruggen

(TECHNO)

Data sensing (Radar), Processing units, High-

ways

0.9 2013/10/18 Erik Nordin

(VOLVO)

Trucks, Highway control functions – Longitudi-

nal control

0.10 2013/10/18 Xavier Savatier

(IRSEEM)

Data Sensing, Perception layer for localisation

and mapping

0.11 2013/10/21 Nereo Pallaro

(CRF)

Used software modules in the CRF demonstra-

tor

0.12 2013/10/21 Jens Klimke (IKA) Additional content to platform hardware, addi-

tional content to longitudinal and lateral con-

trol function in inter-urban environments

0.13 2013/10/23 Jens Klimke (IKA) Executive summary, Introduction, Conclusions

0.14 2013/10/25 Jens Klimke (IKA) Reference list


Contract N. 295364

Version 1.0 of 51

0.15 2013/11/11 Jens Klimke (IKA) Changes from the peer review

1.0 2013/12/10 Jens Klimke (IKA) Finalisation of the draft document, submission


Contract N. 295364

Version 1.0 of 51

EXECUTIVE SUMMARY

In this deliverable the solution design for control functions is elaborated. These test case

functions are used to show the usability and advantages of the DESERVE platform com-

pared to the conventional development of advanced driver assistance systems (ADAS).

In chapter 1 the needs and ideas of the necessity of test case functions for the develop-

ment of DESERVE are outlined. Furthermore a detailed introduction into the topic control

functions in general is done. In this document the requirements on the platform are ana-

lysed. Therefore the platform itself with the hardware (HW) components and the software

(SW) modules are outlined. The development methods described in D2.1.3 [13] form the

basis for this chapter. The description of SW requirements shows the usage of the mod-

ules defined in previous work packages (WPs), mainly described in D1.2.1 [11]. Also the

tool requirements and tool chains, which will be used for developing applications with

DESERVE are reviewed. The tool specifications are analysed in D1.3.2 [12]. In further

course of this chapter the regarded vehicle types, vehicle equipments and environments

are analysed for which the test case functions will be implemented. The needed actuators

of the vehicles are explained to show the usage of the Intervention-Warning-Information

platform (IWI) and in particular the advantage of using the IWI framework.

The main focus of this deliverable is to show, that the platform DESERVE helps to plan

and to implement ADAS easier, safer (error reduction) and cheaper. Therefore the plat-

form modules, defined in previous deliverables, are shortly explained and the connec-

tivity and usability for the test case functions are analysed. Thus the links to other WPs

can be identified and it is shown that the work from SP2 – ADAS development platform is

a convenient basis for the work in WP4.2. On this basis the design of solution approach

for the control functions are developed in chapter 5. Three of the partners in WP4.2 will

implement the control functions on HW to test the platform in demonstrators and in

simulation environments. Therefore an introduction to the software-in-the-loop (SiL),

model-in-the-loop (MiL) and hardware-in-the-loop (HiL) integration tests is described.

Thus the connection to SP5 – Integration and test is closed.


Contract N. 295364

Version 1.0 of 51

1. Introduction

The DESERVE platform [8] is structured in three sub-platforms (see Figure 1). The first

platform is the perception layer which receives data from different sources like sensors,

etc. to pass them pre-processed to the application platform on which the test-case func-

tions are running. The output of these function are steering commands or driver notifica-

tions passed to the IWI platform which executes these commands. The detailed descrip-

tion of the platform can be found in chapter 2.1.

With these generic, predefined and well tested modules of the platform it is possible to

develop ADAS in an efficient way. The definition of appropriate control function to test

the functionality and the productivity in the development by using DESERVE is done in

this deliverable. Therefore the requirements on this function have to be analysed. Ques-

tion to clarify are:

What HW, SW, tool chains should be used?

Which modules are available in DESERVE and useful to be re-used?

What vehicle types have to be considered?

What road environments have to be considered?

After the analysis of these questions appropriate control functions can be found. The next

step is the solution design and the analysis how to implement these functions. The test-

ing and integration concept has to be considered.


Contract N. 295364

Version 1.0 of 51

2. Platform description

In the following chapter the requirements for the control function will be outlined. The fo-

cus of the DESERVE platform is to create a basis for efficient and error-reduced develop-

ment of embedded driver assistance applications for different vehicle types and traffic

environments. Also the price for developing applications from the prototype up to the

running serious products can be reduced by using the platform. In the previous work

packages of the project different requirements on the platform were analysed and de-

fined in several deliverables. Here the defined software, hardware, demonstrators, plat-

form modules and tool chains are highlighted and the advantage to use this solution will

be shown.

2.1. Platform structure

Within the phase of finding and defining of requirements for the DESERVE project, a lot

of reusable modules were outlined.

In D1.1.1 an application database was created in which basic current and near future

ADAS are saved. The database is created in a way that more complex driver assistant

application can be created by using combinations of the database content. The scope of

these applications is to create a larger use of embedded system components.

In Figure 1 the structure of the platform is shown. The perception layer generates a per-

ception horizon and implements multiple modules needed in the following course of this

WP. The application platform is the central processing unit of the platform. On this, the

application will be implemented using the perception data as input. The output is trans-

ferred to the IWI platform which controls the vehicle via its actuators, renders output for

monitors or generates haptic, visual or audible warnings.

In D1.2.1 [11] (restricted deliverable) the perception structure is outlined. For that mul-

tiple perception modules from the public European project interactIVe were used. Some

of them were defined but not developed in interactIVe but will be implemented in DE-

SERVE. But also new modules were identified. The usage of these modules with well de-

fined generic interfaces reduces costs, time and the margins for errors. Some examples

for the perception modules are ADASIS module, Lane course module, and Traffic sign de-

tection module.


Contract N. 295364

Version 1.0 of 51

Figure 1 - DESERVE platform framework

Also modules of the IWI platform were outline in D1.2.1. The vehicle output media can

be used in an easy way by using a framework. The actuators of the car can be manipu-

lated to set throttle angle, brake pressure and steering wheel angle for example.

The application platform consists of different predefined application modules - partly to

be developed in DESERVE - like ACC control, driver intention detection and an IWI man-

ager. In this deliverable some applications will be outlined, which will be developed dur-

ing the DESERVE project to show the advantage of the development platform compared

to a development of these applications “from scratch”. These functions are also used to

test the developed structure of the DESERVE platform.

2.2. Software

Most of the modules described above are software elements, developed with different

programming languages, SDKs and tools. Anyway there are a lot of other tools which can

be part of the platform tool chain but not part of the resulting application. Examples for

software like this are SDKs itself, simulation tools, perception and fusion development,

and databases as input for the application.


Contract N. 295364

Version 1.0 of 51

In D1.3.2 method and tool specifications are outlined [12]. Also different software solu-

tions to implement control functions and to test the DESERVE platform are analysed.

These software solutions can be divided in different software types:

2.2.1. Simulation environments

Simulation environments are used to emulate an artificial reality to simulate for example

sensor outputs, vehicle dynamics and standard driver behaviour. The capabilities are to

test the functions off-line in reproducible test cases and to recreate difficult scenarios

which are dangerous or rare in reality. Also simulators are used to validate perception al-

gorithms and create a huge quantity of test cases with different configurations for em-

pirical validation.

Often virtual vehicles are used in these automotive related simulations. A virtual vehicle

is a mathematical model of a real vehicle. Dependent on the requirements the model im-

plements the longitudinal dynamics of a real vehicle only (engine forces to acceleration,

drive train model). In advanced simulations also the lateral (e.g. steering) and the verti-

cal dynamics (including pitching and rolling) of a vehicle are modelled. Dependent on the

usage the models are very easy but can be very realistic with a respect to detailed physi-

cal effects in the vehicle dynamics.

Important simulation types for this project are:

Sensors and environmental simulators: These simulators are able to calculate arti-

ficial sensor output from given scenarios. The basis is a vehicle model with sen-

sors and the given environment around. The real-time capability can be used to

test HiL, SiL and MiL with these environments [3].

Vehicle dynamic simulators: These simulators implement the (often three-dimen-

sional) dynamics of a vehicle in different driving situations. These simulators are

useful to test the implemented test-case functions in a virtual vehicle. Often the

implementation can be used for demonstrator testing, too. Matlab/Simulink mod-

els, for example, can be developed to control a virtual vehicle in connection with

RTMaps. To implement the model into the demonstrator the Matlab/Simulink code

generation can be used to be ran on a dSpace microAutobox.


Contract N. 295364

Version 1.0 of 51

Real-data playback systems: In these simulator environments realistic data is

processed to test the developed functions. Therefore the data is recorded from

test vehicles (for example sensor output). With these data the reaction or data fu-

sion can be tested. Tools to record those data are EB Assist ADTF and RTMaps.

A possibility to test the platform DESERVE as a hardware solution in a simulation envi-

ronment is to create a HiL model. Therefore the demonstrator is a virtual vehicle or just

captured sensor data. The hardware is connected by defined interfaces to the engine

running the simulation, for example a pc.

In Figure 2 the platform is used as HiL in PELOPS. The perception level of the platform

receives data from PELOPS’ vehicle model, processes them and passes them to the appli-

cation layer which runs the control function. The result is passed to the IWI layer which

implements the connection back to PELOPS’ vehicle model. PELOPS generates the input

for the next time step.

Figure 2 – The DESERVE platform as HiL in PELOPS

The vehicle model of PELOPS is an extensive, dynamic vehicle model and the environ-

mental model is a sub-microscopic traffic model. Sub-microscopic – in this context –

means, that every vehicle is treated as a single independent dynamic object (micro-

scopic) and the vehicle itself is modelled as a real vehicle with drive train, engine,


Contract N. 295364

Version 1.0 of 51

wheels, etc (sub-microscopic). The validated driver model is able to control the vehicle in

a very realistic way on longitudinal scenarios. But also the change of lanes is possible. To

get an advanced functionality which is needed for testing the control functions of this WP

in an inter-urban environment, a driver model for this environment will be developed in

this project in WP3.1. Specifications and needs on this model are described in D3.1.1 [2].

2.2.2. Perception and fusion development tools

In D1.3.2 [12] method and tool specifications are analysed. In this chapter some of these

tools for the perception and fusion development are described.

Perception and fusion development tools provide the users an easy possibility to record,

playback and visualise data from sensors and in-car systems. Moreover a model-based

(visual) or coding framework is provided for easy and quick implementation of functions.

EB Assist ADTF, the Automotive Data and Time-Triggered Framework by the Elec-

trobit Corporation, provides open interfaces, standard software components and the pos-

sibility to capture and process asynchronous data from different vehicle busses. Also the

visualisation (live or playbacked) of the data is possible.

RTMaps is a similar tool to capture, playback, process and visualize sensor data as long

as developing with an included framework. RTMaps is component-based and provides the

possibility to extend the given component library by user-design components based on

the C++-SDK.

These tools are used to implement the control function but also can take the part of

simulation environments. The captured sensor data can be played back and used to gen-

erate real-sensor input for the perception layer. The output can be analysed but might

not be used to generate new input. Compared with the HiL solution design in chapter

2.2.1 the connection to RTMaps or EB Assist ADTF is an open-loop concept.

Another tool is Matlab/Simulink. This software package includes a visual editor to im-

plement controller problems by drag and drop. Therefore multiple blocks with control re-

lated functionality can be added. Every block has input and output ports and can be con-

nected to each other by virtual wires. Simulink is real-time capable and can be expanded

by self-developed blocks. Also a scripting language is included (Matlab) as well as a

C/C++-binding, which can be used in Simulink blocks. With this technology almost every

standard interface (CAN, Ethernet (TCP, UDP), etc.) can be implemented as a Simulink


Contract N. 295364

Version 1.0 of 51

block and used as input or output for the model. Compared to RTMaps and EB Assist

ADTF, Matlab/Simulink focuses on general mathematical problems but not on specific

automotive problems. Anyway Matlab/Simulink is a well known tool in the engineering

world and a lot of modules from the automotive sector are implemented nowadays (e.g.

ASM by dSPACE, see [12]) and makes this tool to fully-fledged part of the DESERVE tool

chain.

2.2.3. Digital maps

For many ADAS digital maps are needed in future. Also present applications like naviga-

tion systems use the data from digital maps. The outputs from these maps for modern

ADAS are detailed information about the road structure (e.g. path and lane data) and

environment (e.g. speed limits and traffic signs). The map can be used to help the driver

with the macroscopic navigation but also for pre-controlling (e.g. light-assist), pre-

warning (e.g. curve-assist) and many other applications. In these cases a prediction of

the following road is needed with more information than sensors can detect. That can ei-

ther be more detailed and accurate information or information which cannot be detected

by sensors due to the distance, technical restrictions of the sensor or obliteration. Thus

an often needed construct generated from digital maps is the electronic horizon

(e-horizon). The e-horizon provides the surrounding map of the host vehicle for calcula-

tions on this area.

A well developed, wide used and standardized e-horizon for ADAS is defined by the

ADASIS v2 protocol (specification: [1]). This ADASIS horizon is defined as a module in

the perception platform of DESERVE. The usage of this module reduces a lot of expanse

on development, testing and validation.

2.3. Hardware

The usage of an in-car pc as a hardware platform is conceivable, since the tools de-

scribed above can be ran on a standard PC under Windows and Linux. However the limits

of those PC solutions are reached quite fast. First of all the bottleneck of a standard PC is

the operating system in CPU-intensive application because a part of the CPU performance

is used to run the operating system itself. An embedded system designed for the work on

one or a few specific tasks is much more efficient and for the series production much


Contract N. 295364

Version 1.0 of 51

cheaper than a PC. Also the size and the power performance are big advantages and

make an in-car pc unusable for the series.

One HW component of the DESERVE platform is a platform based on the dSPACE Mi-

croAutobox II in combination with a FPGA. Some demonstrators by Daimler and CRF,

for example, use this platform to implement control functions in WP4.2 and the Inter-

Urban assist in WP4.6. The partner ika will use a MicroAutobox as HiL with PELOPS to de-

velop a test case function in WP4.2. The prototype of the platform and first release of the

architecture are described in the non-public D2.1.3 [13]. The advantage of this HW plat-

form is that the function can be implemented and compiled in Matlab/Simulink. The plat-

form has common interfaces like Ethernet and CAN and other comprehensive but prede-

fined sets of I/O and is optimized for the real-time usage in vehicles for prototyping.

3. Vehicle equipment

In this chapter standard equipment of test vehicle but also serious production vehicles

are described, which are needed for the control functions. The chapter starts with the de-

scription of data sensing and localisation. Then the data management and processing

units are described. The last sub-section deals with the actuators in which can be ma-

nipulated by the control functions.

In the following chapters the word “ego” is used in combination with vehicle and motion.

The ego vehicle is the vehicle under test or the related vehicle in simulations. The ego

motion is the motion of the ego vehicle.

3.1. Data sensing

Basically, DESERVE control functions are based on a perception layer which

pre-processes outputs of embedded sensors. Nowadays, most of the vehicles are

equipped with proprioceptive sensors informing on the vehicle behaviour and exterocep-

tive sensors enabling environment perception. Proprioceptive sensors collect information

about the internal state of the vehicle, for example current position and motion data

while exteroceptive sensors detect external data from the surrounding of the vehicle like

environmental data (e.g. distance to other road users). Knowledge of the environment

can be extended using a map which is provided by an ADASIS horizon like described in

chapter 2.2.3. Moreover, future vehicles will be equipped with V2V and V2I communica-


Contract N. 295364

Version 1.0 of 51

tion modules allowing information share and gathering from the surrounding environ-

ment. Actually, in DESERVE project, cooperative systems will be considered as sensors.

Depending of the type of sensor output, pre-processing will be required, particularly

when considering exteroceptive sensor as those types of sensors will provide complex

environment data merging static and dynamic information. Pre-processing will consist in

noise removing and data reconstruction using fusion scheme based on sensor model and

environment model (static and dynamic).

One of the challenges in DESERVE platform will consist in designing and integrating

common software pre-processing blocks in the perception layer and guarantying their

portability in embedded systems.

Table 1 summarizes standard and incoming vehicle sensors which can be used in control

functions and a value for the effort of the pre-processing.

3.2. Perception layer for localisation and mapping

One key of control functions will concern the precise positioning of the vehicle. Some ap-

plications like lane keeping will only require relative positioning to the road. In other

cases like intelligent light assistance in curves, may require an absolute precise localisa-

tion. Of the shelf and upcoming GPS can provide absolute localisation with an error less

than few meters but with no guarantee on the accuracy which can be highly degraded in

adverse conditions (lack of satellite, urban canyon). Only D-GPS and/or RTK GPS can

provide sub meter accuracy but they remain too expensive to be considered as standard

equipment in cars. The other issue is the low data sampling of GPS.

Precise positioning will have to be coupled with digital maps containing static but also

dynamic information. Issues concern their storage, refresh and computation time to ex-

tract suitable data from the map.

Range sensors (Radar, LIDAR) and vision sensors are new ways to achieve precise local-

isation. Absolute positioning can be obtained using data from one or several exterocep-

tive sensors (using a fusion scheme) and by correlating sensors measurements with a

precise digital map (also called map-matching).


Contract N. 295364

Version 1.0 of 51

Sensor Data provided Pre-processing

Pro

prio

cep

tive Wheel sensor Odometry +

T°, rain Environmental conditions, adverse conditions

detection

+

Inertial sensors Ego motion +

Exte

ro

cep

tive

GPS Absolute position +

Radar Distance and velocity of other vehicles, ob-

ject detection

++

Lidar Object detection and recognition, in-

terdistance, ego motion, grid occupancy,

mapping

+++

Mono-camera Obstacle detection and recognition, lane de-

tection, light conditions, ego motion (fusion

required), grid occupancy, mapping (to a

scale factor)

++++

Stereovision Same than mono-camera + interdistance,

ego motion, grid occupancy, mapping

+++

V2I/V2I Traffic events, grid occupancy and mapping ++

Table 1 – Sensors for the usage in control functions

In DESERVE, control functions based on precise localisation will necessitate the develop-

ment and integration of software basic modules (in RT-MAPS, ATDTF, etc.) for data proc-

essing, software synchronisation and fusion. To permit their re-use in a plug and play

mode, one has to pay attention to software module interfaces and data encapsulation.

3.3. Data management

Data management is one of main parts used with control functions. Because the DE-

SERVE platform is strongly oriented for evaluating progresses, data management is col-

lection of standard data transfer methodizes and storing techniques. In this chapter some

common transfer standards in the automotive field are described. The central data stor-

age, which is not needed for the control functions in this deliverable is not described and


Contract N. 295364

Version 1.0 of 51

analysed. All needed data (also stored data) is provided by perception platform modules

and are not business of the control functions. Also the processing of raw sensor data is

part of the perception layer and is not analysed and described in this deliverable.

The data transfer between different components (hardware and software) is usually

made by one of three highly developed and specified standards:

CAN-Bus: The CAN-protocol is mostly used transfer method between vehicle body ECUs

(ECM, PCM, transmission, airbags, ABS, cruise control, ESC, audio systems, windows,

doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, etc)

and data processing unit (usually PC, rapid prototyping platform, etc).

Deserve valid processing software (RTMaps, EB Assist ADTF, Matlab/Simulink, PELOPS)

are able to connect directly to the standard CAN bus via USB based devices and in-

put/output software drivers.

Widely used in commercial vehicles and commercial vehicle simulations (including high

level simulators) is SAE J 1939 standard [9] while passenger cars etc. widely use SAE J

22584 standard.

Ethernet (IEEE 802.3): This protocol is used for the data transfer between on-board

PCs and other monitoring and data storage systems. Especially laboratory and simulation

test cases use the Ethernet network (TCP or UDP) for the data transfer to multiple data

processing units. Ethernet has enough capacity to transfer pre-processed function data

and also original sensor data (camera, radar, GPS etc.) to external processing units

(RTMaps, Master/Slave networks, etc.) without data delay.

The standard is well developed and documented. The work with Ethernet is simple and

the packages are protected against data loss by the TCP/IP and UDP protocols.

WiFi (IEEE 802.11): WiFi is a technique for the wireless transfer of data by radio tech-

nology. The standardised protocols TCP/IP and UDP can be used to send data via WiFi se-

curely, protected against data loss and in an easy way due to several framework imple-

mentations. WiFi is often used as an alternative to Ethernet.

WiFi is used for data transfer with DESERVE Control functions in some test scenarios

where cable connection is impossible. Example of these is motorcycle driver monitoring


Contract N. 295364

Version 1.0 of 51

where onboard PC is used for pre processing camera stream and for temporary data stor-

ing, but real time monitoring is not possible onboard.

The advantage of the use of one of the three standards mentioned above is the flexibility,

safety (security standard, protection against loss of data), multiple implementations and

frameworks, and the extensive bundle of documentation.

3.4. Processing units

DESERVE intends to bring in HiL to enhance the development cycle both in efficiency and

effectiveness. Logical candidates for processing units in a HiL environment are: Field-

Programmable Gate Array (FPGA) and Systems-on-Chip (SoC).

An FPGA is an integrated circuit designed to be configured by a developer after manufac-

turing – hence "field-programmable". FPGAs contain programmable logic components

called "logic blocks", and a hierarchy of reconfigurable interconnects that allow the blocks

to be "wired together" – somewhat like many (changeable) logic gates that can be inter-

wired in different configurations. The FPGA configuration is generally specified using a

hardware description language (HDL), similar to that used for an application-specific in-

tegrated circuit (ASIC). In this way a developer can translate its algorithms into HDL and

test and enhance it in a hardware environment before making the step towards ASICs.

A recent trend has been to take the coarse-grained architectural approach a step further

by combining the logic blocks and interconnects of traditional FPGAs with embedded mi-

croprocessors and related peripherals to form a complete "system on a programmable

chip". This new generation of SoCs combines the software programmability of a proces-

sor with the hardware programmability of an FPGA. This gives DESERVE promising levels

of system performance, flexibility, scalability while providing system benefits in terms of

power reduction, lower cost with fast time to market. Unlike traditional SoC processing

solutions, the flexible programmable logic enables optimization and differentiation, allow-

ing designers to add peripherals and accelerators to adapt to a broad base of applica-

tions. Figure 3 illustrates the blueprint of such a commercial-off-the-shelve combined

SoC.


Contract N. 295364

Version 1.0 of 51

Figure 3 - Example of Full-Featured Processing Platform Zyng 7000 [13]

3.5. Actuators

As the control functions act on the longitudinal and lateral vehicle dynamics, the DE-

SERVE platform has to be able to communicate with the vehicle actuators responsible for

the longitudinal and lateral control.

Regarding the longitudinal control, different interfaces in the IWI framework are possible

depending on the vehicle. Common interfaces are:

Desired acceleration

Desired torque

Desired brake pressure and throttle position

Firstly, the desired acceleration can be used as command variable. The underlying accel-

eration controller of the vehicle manages the activation of the throttle or the brake de-


Contract N. 295364

Version 1.0 of 51

pending on the desired acceleration input. Secondly, the desired torque can be used as

command variable. In this case, similarly to the desired acceleration, the underlying

torque controller of the vehicle manages the activation of the throttle or the brake de-

pending on the desired torque input. Thirdly, the control function can act directly on the

brake or throttle by requesting a desired brake pressure or a desired throttle position.

Depending on the vehicle, common interfaces regarding the lateral control are a desired

steering wheel angle or a desired steering wheel torque.

4. Requirements

This chapter outlines the requirements on the control functions. There are two main top-

ics influencing the type of control function. Firstly the different vehicle types are analysed

and requirements for the applications depended on the vehicle type are outlined. In the

second part the standard environments are analysed and also here the requirements are

outlined.

4.1. Vehicle types

In this chapter different vehicle types are analysed which take a role in DESERVE. The

control functions in this WP do not address every vehicle type but an overview should be

given. Firstly a short repetition of needed inputs (perception) and output (IWI connec-

tion) is done. The vehicle types in the following subsections are describing standard vehi-

cles. Of course there are several examples for vehicle of these types with deviating prop-

erties, but for the testing of the platform and its usage these data should be the base of

work.

For the development of the control functions several input control signals should be con-

sidered and their values are different depending on the vehicle type. Also the parameters

related to the vehicle systems and to the vehicle dimensions should be kept into account.

The following lists summarises the previously mentioned features:

Vehicle dimensions:

Length

Width

Height

Weight


Contract N. 295364

Version 1.0 of 51

Input control signals:

Obstacle distance

Obstacle relative speed

Vehicle speed

Vehicle yaw rate

Headway time

Cruise speed

Vehicle system parameters:

Brake system rising time

Brake system overshoot

Steering angle

Transmission

Lateral acceleration

Longitudinal acceleration

The obstacle distance and the relative speed are monitored at each sample time to de-

termine if a warning condition is present or if braking is required. The speed and yaw

rate values of the ego vehicle (vehicle under test) are needed to reconstruct the vehicle

trajectory. The headway time and ego vehicle cruise speed are used above all for the In-

ter-Urban ACC and Full Speed ACC with auto-brake control functions. The parameters re-

lated to the brake system define the braking distance for each kind of vehicle. The fea-

tures related to the steering angle, transmission and acceleration are important for the

collision avoidance and mitigation manoeuvres. Finally, the vehicle dimensions have im-

pact on the modelling of the ego vehicle dynamics.

4.1.1. Passenger cars

The main characteristics of passenger vehicles are presented below:

Weight: 1000 – 1200 kg

Length: 3.7 – 4.5 m

Width: 1.6 – 1.8 m

Height: 1.4 – 1.8 m

Speed: < 220 km/h


Contract N. 295364

Version 1.0 of 51

The ADAS systems based on control functions currently available on passenger cars in-

clude: Adaptive Cruise Control (ACC), Lane Keeping Control (LKC), Automatic Parking

Assist (APA) and Autonomous Emergency Braking (AEB).

In the DESERVE project CRF will equip one passenger car for implementing the Autono-

mous Emergency Braking for pedestrian control function designed to detect pedestrians

and to implement suitable warning and braking strategies (see chapter 5.1.1).

The above mentioned control function will be integrated on vehicle with the Driver Dis-

traction and the Driver Intention functions. The first one monitors the level of driver dis-

traction through the use of internal cameras. The second function should ideally be capa-

ble of correctly inferring the driver intentions.

4.1.2. Light commercial vehicles

The main characteristics of light commercial vehicles (LCV) are presented below:

• Weight: < 3.5 t

• Length: < 12 m

• Width: 2.6 m

• Height: 4.15 m

• Speed: depending on the load

The ADAS systems based on control functions mostly available on Light Commercial Ve-

hicles are: Electronic Stability Control (ESC), Warning and Emergency Braking, Blind Spot

Monitoring, Lane Support Systems and Speed Alert. These systems exist under different

names and exhibit minor differences in functionality depending on the manufacturer.

In DESERVE project CRF will set-up one LCV demonstrator with Autonomous Emergency

Braking Inter-Urban control function designed to detect frontal obstacle that could poten-

tially collide with the ego vehicle. Typically long-range radars are used to detect frontal

obstacles.

The above mentioned control function will be integrated on vehicle with the Driver

Drowsiness and the Driver Intention functions. The first one monitors the driver drowsi-

ness by biological parameters sensors. The second function should ideally be capable of

correctly inferring the driver intentions.


Contract N. 295364

Version 1.0 of 51

4.1.3. Trucks

Trucks are typically used for transporting goods, but trucks can vary greatly in size,

power, and configuration. There are various types of truck types (some shown in Figure

4), e.g. there are trucks for:

General cargo

Waste and recycling

Construction

Petroleum

Agriculture

Timber

Public services

Figure 4 – Example of trucks for various services

There are also many combinations of trucks combined with trailers, for being able to

adapt to the amount of goods transported. Typical combinations are shown in Figure 5.

In this project a heavy commercial rigid truck (without trailer) will be used as a demon-

strator. This truck type normally operates efficiently in inter-urban and highway envi-

ronments. The control function to be developed for this demonstrator includes adaptive

cruise control (ACC) with advanced emergence braking system (AEBS).

Main characteristics for the Volvo heavy commercial truck are:

Weight: 3.5 t – 60.0 t (total weight with goods)

Length: 7.1 – 25.25 m (total length with trailers)

Width: 2.495 m

Height: 3.474 m

Speed: < 90 km/h


Contract N. 295364

Version 1.0 of 51

Figure 5 - Truck-trailer combinations

4.1.4. Motorcycles

The dynamic and practical differences between motorcycles and other vehicle types are

significant. The handling, various forces and physical phenomena affect of motorcycles

are different to four-wheeled vehicles.

The wide scale utilisation of advanced rider assistance systems (ARAS) functions on mo-

torcycles is limited, and ABS and Traction Control Systems are in the beginning to gain

popularity and acceptance in wide scale commercial markets. The transferability of ADAS

functions into a PTW platform is poor, at best. For instance, automated steering and

braking functionalities are not applicable on a motorcycle, whereas they might be of con-

siderable advantage in a car. Many applications are nonetheless PTW-operable and highly

useful as warning or notification system.

CAN busses or similar data transferring systems are only now becoming more common

on PTWs. This means that the CAN bus based ADAS functions that have been proven to

give high added value to drivers, are not directly transferrable to a majority of PTWs as

such, because without a CAN bus another method of communication has to be built.

Ramboll has equipped their pilot vehicle - a Yamaha FZ1 - with a self-made CAN bus.

This has enabled the work on rider monitoring and drowsiness detection given the high


Contract N. 295364

Version 1.0 of 51

interoperability of several devices. Ramboll is looking to develop many other kinds of

ARAS functions and traffic safety contributions as well, including but not limited to:

Blind spot detection

Emergency braking ahead

Electronic emergency brake light

Anyway, like written above the lateral or longitudinal control of motorcycles is not part of

the current subject of research, hence motorcycles are not subject of matter in this WP.

4.2. Environments

In this chapter the environments are described. In the following of this document differ-

ent control function will be identified which are operating on different vehicle types but

also on different road scenarios namely urban and inter-urban road scenarios, as long as

highway scenarios. The focus of the chapter is the description of these environments to

identify requirements and needs.

4.2.1. Urban

The typical urban environment is characterised by:

• Type of road

• Type of intersection

• Speed: 30 – 80 km/h

• Structured lighting, traffic lights

According to statistics, the accident situations in urban traffic mainly address the follow-

ing scenarios:

• Car to car rear accidents, with lead vehicle stopped or decelerating

• Pedestrian crossing on a straight road without obstruction

• Pedestrian crossing on a straight road with obstruction

• Pedestrian crossing a junction during a turning-off manoeuvre

In Figure 6 four possible scenarios related to car to rear car possible accidents are de-

picted. The figure is related to scenarios with the leading vehicle static or slower (decel-

erating or with lower speed) than the ego vehicle.


Contract N. 295364

Version 1.0 of 51

Figure 6 - Rear to rear accidents scenarios

It has been noted that the accidents in the presence of the previous scenarios are more

frequent during day-time, due to the higher traffic density. However the use of radar

sensor allows a correct operation of the control system also during night time.

In urban environments, multiple vehicle types are using the roads. Not only motorized

vehicles but also bicycles, for example, are part of the urban traffic. Next to vehicles also

pedestrians are notable road users which are a big accident factor in urban scenarios.

Figure 7 shows the main scenarios involving pedestrians crossing without obstruction.

Figure 8 shows the possible scenarios with pedestrians crossing the road in presence of

an obstruction for the approaching ego vehicle.

In Figure 9 the possible turning scenarios involving pedestrians are presented.

Figure 7, Figure 8 and Figure 9 include the objects A: host vehicle and B: possible colli-

sion object. The letter F marks an object as a pedestrian.


Contract N. 295364

Version 1.0 of 51

Figure 7 - Pedestrian accidents in crossing scenarios without obstructed

view [4]

Figure 8 - Pedestrian accidents in crossing scenarios with obstructed view [4]


Contract N. 295364

Version 1.0 of 51

Figure 9 - Pedestrian accidents in turning scenarios [4]

4.2.2. Inter-Urban

The typical inter-urban environment is characterised by:

• Type of road

• Type of intersection

• Speed: 30 – 80 km/h

• No structured lighting, few traffic lights

In Figure 10 it is presented a possible scenario where the host vehicle is approaching

with vehicle speed a stopped vehicle.

Figure 10 - Host vehicle approaching to a standing vehicle in the same lane

Another possible scenario (Figure 11) regards the host vehicle that is approaching with

speed to a decelerating or slower vehicle that is proceeding with speed .

Compared to urban scenarios inter-urban scenarios are of easier structure. In general the

structure of inter-urban roads is well defined by the local law. Different road and inter-

section types are defined in [5] for German inter-urban roads. For smaller, less used in-

ter-urban roads the average speed is lower.


Contract N. 295364

Version 1.0 of 51

Figure 11 - Host vehicle approaching to a decelerating vehicle in the same lane

In the following the standard elements of inter-urban scenarios are listed in Table 2.

Element Description

Linear Road

Element

Multiple-lane road with multiple traffic directions. The number of lanes

can change and also the main traffic direction can change. In some

cases one lane is used by both traffic directions. On large inter-urban

roads the linear road element can have the structure like on highways

(see chapter 4.2.2)

Access and

Exit (Link)

Known from the highway environment and described below (see chap-

ter 4.2.2). The traffic threads into the other.

Intersections Traffic node of two or more roads with interaction of the traffic partici-

pants. Often one road is prioritised. Sometimes traffic lights control

the traffic flow. There are different types of intersections categorised

by: junction (comparable to highway junctions), crossing, confluence.

The structure depends on the environment (road type), traffic volume,

etc. The traffic turns from one to the other road or threads in case of

access and exits (see above).

Round-about Another node of multiple roads. A round-about has the advantage of

clear and easy priority rules without many traffic signs and traffic

lights. The traffic threads into the round-about traffic and threads onto

the wished road.

Traffic lights Traffic lights often control the traffic at intersection but also can be

used to control the traffic flow in the longitudinal direction only

(bridges, tunnels, pedestrian crosswalk, etc.).

Table 2 - Inter-urban road structure elements

The interaction with pedestrians is possible on inter-urban roads but is not needed in this

WP and is not analysed here.


Contract N. 295364

Version 1.0 of 51

The standard manoeuvres are

Free driving (controlling speed)

Approaching (controlling speed by distance)

Following (keeping distance)

Overtaking (trajectory control, speed control)

Lane-change (trajectory control)

Turning on intersections (trajectory control)

Starting, stopping (speed control)

The overtaking manoeuvre on inter-urban roads can be divided in two kinds of overtak-

ing. On the one hand, an overtaking manoeuvre can be performed by changing the lane

to a second fast lane. This is needed to overtake a fast or wide vehicle, which blocks the

host lane. On the other hand an overtaking on the host lane can be performed if there is

an obstacle but on the very right side. The overtaking vehicle is keeping a safety distance

and passes the object. Possible objects can be far right moving, slow vehicles (tractors,

bicycles, mopeds, etc.), pedestrians, walking close to the host lane or static obstacles,

like parking cars, small construction sides, etc.

Like in the urban environment many different vehicle types are using the roads. But

compared to urban scenarios the structure is clearer. Pedestrians, for example, are

crossing at special traffic points like traffic lights. Also the surroundings are often opener

than in urban environments due to the fact, that there are less parking cars and buildings

close to the road.

4.2.3. Highway

Highway is used in this deliverable as generic term for motorway, freeway, expressway,

Autobahn, autostrada, autopista, autoroute and autosnelweg.

The Highway environment can be characterised from both, supply and demand perspec-

tive.

Starting with the supply perspective, the highway provides an unhindered flow of traffic,

with no intersections or property access. They are free of any at-grade crossings with

other roads, railways, or pedestrian paths, which are instead carried by overpasses and

underpasses across the highway. Entrance and exit to the highway are provided at inter-

changes by slip roads (ramps), which allow for speed changes between the highway and


Contract N. 295364

Version 1.0 of 51

arterial roads and collector roads. On the highway itself, opposing directions of travel are

generally separated by a central reservation containing a traffic barrier.

The typical highway environment is characterised by:

Speed: 60 – 130 km/h (in some countries less, e.g. 120 km/h in Finland, or

100 km/h in winter times, in others more e.g. unlimited in Germany [10]

No traffic lights, no structural lightning

No crossing traffic, no intersections

No rightfully opposing directions

The speed range is hard to define, thus it depends on the laws in the respective coun-

tries. The working range for control function for highways generally does not accord to

the respective speed limit but to the limits of the vehicle. This can be a value more than

200 km/h for middle and high class vehicles. In general the speed (or working velocity)

depends also on the vehicle types and have to be analysed in detail in the further devel-

opment of the functions. Anyway in general there are neither very slow or standing vehi-

cles (< 60 km/h) nor unmotorised vehicles (e.g. bicycles) nor pedestrians on the high-

way. In special cases (traffic jams, accidents, etc.) it can be that vehicles are standing or

moving very slow or people are standing or walking next to the road.

Highways are of simple structure compared to urban and inter-urban road scenarios.

Highways consist of the structure elements outlined in Table 3.

Highways do not have intersections, (sharp) turns, etc. Traffic lights are restricted to

tunnels and moveable bridges. The traffic lanes are in general of constant width and have

well visible lines. Highways consist of two or more multiple-lane carriageways. Each car-

riageway is one directional, which means that the traffic directions are strictly divided to

different carriageways and are connected only by traffic nodes. In regular situations

ADAS do not have to pay attention to up-coming or crossing traffic. In irregular situations

ADAS do have to pay attention to ghost drivers, i.e. drivers who drive unlawfully in the

opposite directions on a carriageway. For the time being we do not consider a control

functions that reacts on ghost drivers. The scheme of a typical highway lane structure is

shown in Figure 12.


Contract N. 295364

Version 1.0 of 51

Element Description

Linear Road

Element

To or more multiple-lane carriageway with one traffic direction. The

number of lanes can change but there is no lane from the side not be-

longing to the main carriageway.

Entrance Via a slip road (on ramp), i.e. an additional lane outside of the main

carriageway on the right which approaches from the right side and

ends after a few hundred meters (sometimes less). The oncoming traf-

fic uses the lane accelerate to the appropriate speed and performs a

lane change to get onto the main carriageway.

Exit Also via a slip road (on ramp), i.e. an additional lane at the right side

of the main carriageway. The lane begins beside the carriageway and

separates to the right. Leaving traffic performs a lane change to this

lane to get off the main carriageway and decelerates to the appropri-

ate speed for the new road to enter.

Table 3 - Highway road elements

Figure 12 - Lane structure scheme of a typical highway section


Contract N. 295364

Version 1.0 of 51

The manoeuvres which can be performed by a control function, in case it is needed, are:

Free driving (controlling speed)

Approaching (controlling speed by distance)

Following (keeping distance)

The response times and distances on a highway should meet the typical speeds, vehicles

are driving with, in between 17 m/s (60 km/h) and 36 m/s (130 km/h). Driving at a

highway at 36 m/s, a reaction time of the vehicle driver of a second will take 36 meters.

In case of a brake distance of 80 m the trigger for collision avoidance should fire at least

at a distance of 115 meter from the object.

These manoeuvres are longitudinal control but include the lane-keeping which is lateral

control of the vehicle. More over the manoeuvre lane-change has to be performed in case

the functionality is needed. The manoeuvre overtaking is performed as a sequence of

manoeuvres mentioned above, namely:

1. Lane change

2. Free driving, approaching or following

3. Lane change


Contract N. 295364

Version 1.0 of 51

5. Solution design for the control functions

In this chapter the solution design is done on the basis of the outlined requirements and

the platform analysis. The chapter is divided in the environments the control function

works in. For each control function the usage of the platform, particularly of the modules,

are described. The functionality and first ideas of implementations are given and a solu-

tion approach for testing is outlined.

5.1. Urban control functions

5.1.1. Longitudinal control

The Pedestrian AEB function aims at avoiding low speed accidents with pedestrians. It

can be based on one sensor (mono camera, stereo camera, mid-range radar (MRR) or

LIDAR) or two fused sensors (mono camera plus radar). The sensor data allows detecting

and classifying the obstacles, identifying shapes and characteristics typical of pedestri-

ans.

Figure 13 shows the area covered by a mono-radar system and managed by the control

algorithm.

Figure 13 - Area managed by the control algorithm

The control algorithm indicates the presence of each pedestrian in the highlighted area.

In particular if the pedestrian is identified into the orange area and it has a lateral speed

40 m

Warning

Intervention


Contract N. 295364

Version 1.0 of 51

generating a trajectory inside the red zone, the system warns the driver with, for in-

stance, an acoustic or visual signal.

If the pedestrian is inside the red zone the control algorithm operates the automatic

brake to avoid the collision between the vehicle and the pedestrian or, if this is not feasi-

ble, it reduces the impact speed below 30 km/h.

The dimensions and the shape of this zone can change depending on the dynamical

properties of the equipped vehicle (longitudinal speed, steering angle, yaw rate, etc.) and

also the threshold between the collision avoidance and the collision mitigation zone will

depend mainly on the vehicle speed but also on road condition (friction), brake status,

tyre condition, etc.

For the AEB Pedestrian function CRF will equip a passenger car as vehicle demonstrator.

The vehicle will integrate a medium-range radar and a stereo camera placed behind the

windshield. The radar sensor determines the position and the relative speed vector of re-

flectors, and it detects many reflectors simultaneously.

According to the draft Euro NCAP assessment protocol (AEB test procedures, [7]), the

AEB pedestrian system should be validated with speed range 10 – 60 km/h, increasing

the host vehicle speed of 10 km/h at each test and decreasing it of 5 km/h when the test

fails.

The functional blocks diagram, shown in Figure 3.2, describes the main software modules

of the following functions integrated on the CRF passenger car demonstrator:

• AEB Pedestrian

• Driver Monitoring (Driver Distraction)

• Driver intention

The modules involved in the AEB Pedestrian control function are highlighted in red.

The AEB Pedestrian function includes both modules of perception and application plat-

forms.

The Frontal Object Perception module aims at detecting every relevant stationary and

moving obstacle in front of the host vehicle. Advanced filtering techniques and data fu-

sion are executed in order to extract additional information from the sensor data. The

module receives as input the sensor signals (mid-range radar, stereo camera) and the

data from the Vehicle Trajectory Calculation module. The output is based on a list of de-


Contract N. 295364

Version 1.0 of 51

tected objects (stationary and moving) with the required attributes. It can be used by the

Vulnerable Road Users module that detects, classifies and tracks pedestrians in front of

the host vehicle. The VRU module is able to fuse information coming from a forward look-

ing radar sensor, capable of accurately measuring the range to the object, and a vision

sensor providing classification capability and accurate lateral positioning in order to get a

sufficiently reliable pedestrian detection.

Figure 14 - Functional block diagram for AEB pedestrian (CRF demonstrator)

The Vehicle Trajectory Calculation module provides the trajectory of the host vehicle as a

list of points. The aim is to predict the driver’s intention few seconds in advance estimat-

ing the path of the host vehicle and its dynamics with respect to a given fused road ge-

ometry.

The Lane Recognition module evaluates the position and geometry of high-contrast lane

markers of the host vehicle lane on the road. This module uses a stereo camera as sen-

sor input. The ADASIS Horizon module allows to extract the host vehicle position data as

well as the road segment attributes from the digital map.


Contract N. 295364

Version 1.0 of 51

The outputs of the former modules are sent to the Application platform. In particular, the

Target Selection module determines which vehicle is the most relevant target obstacle

related to the current and predicted driving situation. The priority of the target depends

on its trajectory in comparison to that of the host vehicle.

The Threat Assessment module classifies and assesses the longitudinal and lateral risks

associated to the current situation based on specific measures like TTC (time-to-collision)

and TLC (time-to-lane-crossing). It also calculates the threat for a new alternative trajec-

tory.

The IWI module is based on Information, Warning and Intervention manager. The Infor-

mation Manager deals with the information to be provided to the driver. The Warning

Manager analyses the results of the Threat Assessment and the Driving Strategy modules

and makes the final decision about when to issue a warning and when to suppress it. The

Intervention Manager analyses the results of the Threat Assessment and the Driving

Strategy modules and makes the final decision about when to issue an intervention and

when to suppress it. The Vehicle Control module determines in case of an intervention

the desired longitudinal deceleration request based on the results of the components tra-

jectory planning and control. If a braking action is needed it controls the correct amount

of braking to ensure that the vehicle is braked safe.

5.2. Inter-urban control functions


As control function acting in an inter-urban environment, ika will develop an Inter-

Urban Adaptive Cruise Control (IU-ACC). In addition to conventional ACC systems as

described in the ACC ISO Norm [6] the IU-ACC will:

Cover a speed range of 0-180 km/h

Consider speed limits and reduce set speed where appropriate

Consider road topography (mainly curvature) and reduce temporary speed (not

set speed) where appropriate

React on commands from other trajectory control (lateral control, see chap-

ter 5.2.2)

The IU-ACC is not designed to work in intersection areas. The functionality of checking

and regarding the priority is very complex and not needed to test the platform. Also


Contract N. 295364

Version 1.0 of 51

other “advanced” situation happening on inter-urban roads are not considered. Situations

like construction sites, parking vehicles, pedestrians moving close to the road in longitu-

dinal direction and slow right-moving vehicles are considered by the lateral control func-

tion of the Inter-Urban assist by ika. The lateral control element can prescribe a velocity,

for example in the mode of safe passing. Then this velocity overlays the set speed of the

ACC. Anyway if the ACC reduces the set speed or the controlled speed due to the dis-

tance to a leading vehicle the lowest speed is relevant.

The above described additional functions will be realised by taking into consideration data

coming from the perception platform and the lateral control function. In addition, data

coming from car-to-car or car-to-infrastructure communication can be included in the

sensor fusion if applicable but is not planned to use in this WP.

The IU-ACC uses digital map data by accessing the ADASIS module of the perception

platform to receive information about speed limits and curvature data of the road ahead

to set the ACC speed or to reduce the current speed to safely and comfortably pass a

curve (reduced lateral acceleration). Also the digital map is used to calculate the point in

time for driver take-over in case of upcoming intersections or other reasons for a system

switch-off (end of inter-urban area, etc.). In this case audible and visual notifications are

given by the vehicle to signalise the driver to take over the control. These notifications

are performed by using the DESERVE IWI platform. Other modules from the perception

platform to be used by the IU-ACC are the Frontal Near Range Perception module (FNRP)

to detect a leading vehicle with its relative speed and distance to the host vehicle and the

Frontal Object Perception module (FOP) to calculate a strategy for the upcoming sce-

nario. The near range data are used for the conventional ACC functionality – to keep the

desired distance. The Traffic Sign Detector (TSD) module is used to get the current speed

limit and to detect special situations which are not saved in the digital map (construction

sides, etc.).

The IWI framework is used to manipulate the throttle, brake and steering wheel. Also like

described in chapter 5.1.1 the framework will be used to give notifications and warnings

to the driver.

The IU-ACC will be developed and tested in a virtual environment using the traffic flow

simulation programme PELOPS as core element. Therefore the model will firstly be con-

nected as a standard Matlab/Simulink-model to PELOPS to control the host vehicle. This

MiL approach is used to test the functionality of the control function. In a second step the


Contract N. 295364

Version 1.0 of 51

model will be compiled for the MicroAutobox II by dSPACE. This device can be connected

to PELOPS by CAN-Bus, thus the complete system can be tested with functionality, inter-

faces and communication module.

In chapter 2.2.1 the HiL approach with PELOPS and the Autobox is described. Figure 2

shows the scheme of the implementation. PELOPS consists of the three models driver

model, vehicle model and environmental model, which are working in a closed loop. The

driver model – an implementation of a virtual driver – controls the vehicle, which gener-

ates data for the environmental model (position data, etc.). The environmental model is

used to generate an e-horizon as input for the driver model in the next calculation step.

The control function intercepts the driver model input and overlays it with its own control

data in the case it is active. In the case the system is deactivated, the driver model out-

put is passed through and controls the vehicle model.

CRF will develop an Inter-urban AEB. The aim of this control function is to detect the

presence of forward vehicles and to determine their position respect to the host vehicle,

in order to warn the driver in response to the detection of a likely collision and to apply

an automatic brake to reduce the vehicle speed and potentially avoid the collision.

The inter-urban AEB function is mostly used for dual carriageway and motorways.

In order to work at higher speed, the system uses long-range radars to monitor higher

distances in front of the host vehicle. A main advantage of using a radar sensor is that

the system is suitable for all weathers and lighting conditions. The radar data is analysed

to determine if the host vehicle could potentially collide with any frontal obstacle.

The system determines the relative speed of the obstacles respect to the host vehicle.

For vehicle speed range 0 – 30 km/h (low-speed) the system allows to execute an auto-

matic braking manoeuvre to avoid the impact with the obstacle. When the speed of the

host vehicle is higher than 30 km/h the control function executes a collision mitigation

manoeuvre.

Visual and audible warning signals, as well as a brake jerk (haptic warning) can be given

to the driver to alert him in case of danger. If there is no reaction from the driver, the

system will itself apply heavy braking. Inter-urban AEB, differently by the city AEB, oper-

ates over the speed range 50 – 80 km/h. Some systems designed to operate primarily at

Inter-Urban speeds may also provide benefit in city driving. It may at least be able to

warn the driver and provide some mitigation effects.


Contract N. 295364

Version 1.0 of 51

The AEB function works in presence of standing and moving obstacles that have the

same direction and are in the same lane of the host vehicle.

To implement the Inter-urban AEB function CRF will equip a Light Commercial Vehicle. In

particular a long-range radar and a mono camera (or stereo) are used.

According to the Euro NCAP assessment protocol (AEB test procedures, [7]), the system

will be validated in the speed range 30 – 80 km/h increasing the host vehicle speed of 10

km/h at each test and decreasing it of 5 km/h when the test fails.

5.2.2. Lateral control

The trajectory control can be implemented as a combination of longitudinal control in the

mode free moving (control of velocity, ACC) and the lateral control. For the lateral control

the controller of the lane-keeping can be used with the difference that the control vari-

able is not the distance from the centre of the lane but the distance to the trajectory.

To generate the trajectory a classification of the situation is needed firstly. There are

several macroscopic situations which can be outline with the consequences for the lateral

control and the command for the longitudinal control:

1. Free way without obstacles: Control on midline. ACC controls speed.

2. Leading vehicle without obstacles: Control on midline. ACC controls distance.

3. Obstacle on the very right side with upcoming traffic: Generate trajectory to keep

safety distance if possible, but without leaving the lane. Reduce velocity if needed.

If manoeuvre not possible stop the vehicle.

4. Obstacle on the very right side without upcoming traffic: generate trajectory to

keep safety distance, if needed by overdriving the lane border. Reduce velocity if

needed.

5. Obstacle: no lateral control. Stop the vehicle (longitudinal control).

In Figure 15 a trajectory scheme for safe passing is shown without leaving the lane is

shown. Of course this is only possible, if the obstacle object (blue vehicle) is on the very

right side and is not reaching into the lane too much. The upcoming vehicle (yellow) can

keep its path (middle of lane). The host vehicle (red) moves from the middle of the lane

to the left to keep a safe distance to both vehicles.


Contract N. 295364

Version 1.0 of 51

Figure 15 – Safe passing vehicle

In this control function the trajectory for those situations will be calculated. The control

function consists of the following modules:

Decision module, which calculates which manoeuvre is performed (lane keeping or

passing, stopping)

Trajectory planner, calculates depending on the upcoming traffic a trajectory to

pass

Controller, which controls whether on the middle of the lane or on the trajectory

The modules described above need the following information from the perception plat-

form:

The VRU module is used to detect obstacles which can be safely passed by the host vehi-

cle in the case it is not a static obstacle but persons or bicycles, etc. The Frontal Near

Range Perception and the Frontal Object Perception modules are used for the decision

module and for the trajectory planning. With the information from this module a path be-

tween obstacle and upcoming traffic can be calculated. Also needed for this module are

the Lane Course and the Lane Recognition module to detect the lane information. The

Relative Positioning to the Road of the Ego Vehicle module (RPR) is needed as input for

the lane keeping controller. The controller for the trajectory can either be done by rela-

tive values so the RPR module is needed or it can work with absolute positioning data

which have to be very accurate. For this high precise positioning the EVP module (En-

hanced Vehicle Position) is needed.


Contract N. 295364

Version 1.0 of 51

5.3. Highway control functions


Volvo will implement a full speed ACC with AEBS functionality using the DESERVE plat-

form. The Adaptive Cruise Control (ACC) keeps a safe distance to the vehicle in front by

controlling the accelerator and all available brakes. If there is a risk of collision, warning

lights are projected on the windscreen. The Advanced Emergency Brake System takes

this one step further. It automatically assists you in emergency braking if an impact is

imminent.

Adaptive Cruise Control is controlling the vehicle speed adaptively to a forward vehicle by

using typically information about:

Ranging to forward vehicle

The motion of the ego (ACC required) vehicle

Driver commands

Based upon the information acquired, the controller (identified as “ACC control strategy”

in figure 2.1) sends commands to actuators for carrying put its longitudinal control strat-

egy and it also sends status information to the driver.

Figure 16 - Functional ACC Elements [6]

AEBS warns the driver when the ego vehicle encounters the situation when a forward ve-

hicle in the subject’s trajectory becomes a potential hazard. This is typically done by us-

ing information about:


Contract N. 295364

Version 1.0 of 51

The range to forward vehicles

The time to a potential collision

The grade of warning provided to the driver

When sensors detect a potential collision it doesn’t take immediate action to avoid it.

Once the sensing system has detected that the collision has become inevitable regardless

of braking or steering actions then emergency braking is automatically applied to avoid

collision.


Contract N. 295364

Version 1.0 of 51

CONCLUSIONS

In this deliverable the requirements of the test-case functions are analysed. The connec-

tion to the previous WPs is shown by describing how the identified and defined software

and hardware modules of the platform can be used. The analysis of the requirements

showed that the functions have to be implemented for different vehicle types from trucks

and light commercial vehicles to passenger cars. This is necessary to show that the plat-

form works for these common vehicles which are the core for the automotive industry

and the broad research and development on ADAS. Next to the different vehicle types

the environment has an influence, like it is shown in the deliverable. Due to the fact that

the environments provide fundamental differences in structure and usage by vehicles,

the control functions have to be developed for the main road environments, namely

highway, inter-urban and urban environments. Appropriate combinations of vehicle

types, environments and ADAS function are defined. To cover these combinations, solu-

tions for five showcase control functions were designed in this deliverable:

A Pedestrian AEBS for urban scenarios and passenger cars

An Inter-Urban AEBS for implementation in an LCV

An Inter-Urban ACC (full-range) for the implementation in passenger cars

An Inter-Urban Assist for the lateral control of a passenger car with lane keep-

ing and safe obstacle passing functionality

A Full-Range ACC for heavy trucks on highway environments

These test case functions are the use cases of the DESERVE platform in WP 4.2. The de-

velopment which will be described in the following deliverable D4.2.2 will show that the

usage of the three platforms of DESERVE (perception, application and IWI platform) are

very useful to implement such control functions more efficient, easier and faster com-

pared to the development from scratch. The reuse of pre-developed software modules

and versatile hardware platforms will reduce the work load and the necessary testing of

each function module.

The testing of these functions will be performed in simulation environments and partly in

demonstrators. The demonstrator testing will be done in SP 6 by the related partners.

The testing in the simulation environment will be done within the development of the

functions to verify the functionality and correctness. The reporting will be done in the fol-


Contract N. 295364

Version 1.0 of 51

lowing deliverable D4.2.2. The development software and SDKs are coordinated with the

work of the previous WPs. Tools for developing these functions are Matlab/Simulink and

RTMaps in combination with the MicroAutobox II by dSPACE as embedded HW. As HW-

interfaces Ethernet and CAN-Bus are used, due to standards in the automotive field. The

input for the control functions are generated by the perception modules as long as they

are implemented. If not, the data from the simulation will be structured in the same way,

so that the module output can be simulated. The IWI platform is used to generate driver

related information like warnings and notifications and to manipulate the actuators of the

vehicles. Also here the IWI framework will be used in the way it is possible at this state

of the project.


Contract N. 295364

Version 1.0 of 51

REFERENCES

[1] Durekovic, S. et al. ADASIS v2 Protocol, 2009, Version 0.60.

[2] Fruttaldo, S. et al. D3.1.1 - Standard Driver Model definition. Public project deliver-

able. DESERVE, 2013.

[3] Hochstädter, A., Ehmanns, D., and Neunzig, D. PELOPS as a Tool for Development

and Configuration of Driver Assistance Systems. http://www.ika.rwth-

aachen.de/forschung/veroeffentlichung/1999/08.-09.02-3/. Accessed 18 October

2013.

[4] Meinecke, M.-M. et al. D2.1 User Needs and Requirements for VRU protecting sys-

tems based on multipurpose narrow-band radar. Public project deliverable. ARTRAC,

2012.

[5] N.N. Richtlinien für die Anlage von Straßen (RAS) - Teil: Knotenpunkte (RAS-K), Ab-

schnitt 1: Plangleiche Knotenpunkte (RAS-K-1), 1996.

[6] N.N. ISO 15622:2010, Intelligent transport systems - Adaptive Cruise Control sys-

tems - Performance requirements and test procedures, 2010.

[7] N.N. NCAP assessment protocol, AEB Test Procedures, 2012.

[8] N.N. DESERVE Project. www.deserve-project.eu. Accessed 23 October 2013.

[9] N.N. SAE J1939 - Recommended Practice for a Serial Control and Communications

Vehicle Network, 2013.

[10] N.N. Wikipedia - Speed limits by country.

http://en.wikipedia.org/wiki/Speed_limits_by_country. Accessed 21 October 2013.

[11] Pallaro, N. et al. D1.2.1 – Development Platform Requirements. Non-public project

deliverable. DESERVE, 2013.

[12] Pallaro, N. et al. D1.3.2 - Method and Tools Specifications. Public project deliverable.

DESERVE, 2013.


Contract N. 295364

Version 1.0 of 51

[13] Rolfsmeier, A. et al. D2.1.3 Development method. Non-public project deliverable.

DESERVE, 2013.

[14] XILINX. www.xilinx.com - All Programmable SoC.

http://www.xilinx.com/products/silicon-devices/soc/. Accessed 21 October 2013.

control functions solution design - deserve project · 2014-12-03 · control functions solution...

Documents