Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 2 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 3 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.1. Longitudinal control ..................................................................................................... 41
5.2.2. Lateral control ............................................................................................................ 44
5.3. Highway control functions ..................................................................................... 46
5.3.1. Longitudinal control ..................................................................................................... 46
CONCLUSIONS ..................................................................................................... 48
REFERENCES ....................................................................................................... 50
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 4 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 5 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 6 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 7 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 8 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 9 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 10 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 11 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 12 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 13 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 14 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 15 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,
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 16 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 17 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 18 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-
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 19 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).
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 20 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 21 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 22 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 23 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-
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 24 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 25 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 26 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 27 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 28 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 29 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 30 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 31 of 51
Figure 7 - Pedestrian accidents in crossing scenarios without obstructed
view [4]
Figure 8 - Pedestrian accidents in crossing scenarios with obstructed view [4]
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 32 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 33 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 34 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 35 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 36 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 37 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 38 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 39 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-
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 40 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 41 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
5.2.1. Longitudinal control
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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 42 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
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 43 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 44 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 45 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 46 of 51
5.3. Highway control functions
5.3.1. Longitudinal control
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:
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 47 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 48 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-
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 49 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 50 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.
Control functions solution design Public Copyright DESERVE
Contract N. 295364
Version 1.0 Page 51 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.