Professional Documents
Culture Documents
Transition to
Development
approach
series system
Flexibility
Algorithm
Sensor
support
interface
fusion
Direct ECU
implementation
Coding-based
Model-based
Hybrid
Not necessary
Manual reimplementation
Template-based
code generation
Novel code
generation
via
long
very low
none
ECU; direct
long
low
none
PC; direct
medium
low
limited
short
high
full
additional
hardware
PC; direct
Keywords: Data Fusion, Data Logging, ADAS, Perception Model, Bayesian Filtering,
Code Generation, Rapid Prototyping
Author: Norman Mattern, Head of Products & Services, BASELABS GmbH
Introduction
Current developments in the domain of Advanced Driver Assistance Systems (ADASs)
handle more and more complex functions. This increased complexity leads to more
sensors being mounted on vehicles and puts a focus on the fusion of data of these
numerous sensors. This data fusion offers different degrees of freedom but also
algorithmic and implementation challenges. For that reason, the next section lists
typical approaches how the algorithmic processing of a system using multiple sensors
can be partitioned. Independent from the actual partitioning, the algorithms need to
be designed as well. They finally need to be available for an automotive electronic
control unit (ECU) for the later use in series production. Therefore, the paper at hand
additionally describes different scenarios including a novel approach how the
transition from a prototype to an ECU can be supported by tools in the context of
signal processing for ADAS sensors like radars, laser, and cameras. In the last section,
tools for the design of data fusion algorithms are compared.
Radar
sensor data
Algorithm
(Tracking)
tracked objects
Algorithm
(Function)
therefore centralized processing of all sensor information incl. raw data can be an
advantage. The central data fusion architecture offers this benefit and is addressed in
the next paragraph.
Stereo Cam
sensor data
Algorithm
(Tracking)
tracked
objects
Mono Cam
sensor data
Algorithm
(Tracking)
tracked
objects
Algorithm
(Track-to-track
Fusion)
Short Range
Radar 1
sensor data
Short Range
Radar 2
sensor data
Long Range
Radar
sensor data
Algorithm
(Data Fusion /
Tracking)
Algorithm
(Function)
System of OEM
or supplier
tracked
objects
tracked
objects
System of OEM
or supplier
Stereo Cam
sensor data
Supplier 1
Mono Cam
sensor data
Algorithm
(Data Fusion /
Tracking)
Supplier 2
Radar 1
tracked
objects
Algorithm
(Function)
System of OEM
or supplier 6
sensor data
Supplier 3
Radar N
sensor data
Supplier 4
System of OEM
or supplier 5
3. Hybrid development
The following sections will describe the different approaches in more detail.
Furthermore, the involved system development set-ups will be presented on a
simplified example. This example assumes that a certain algorithm, be it tracking or
other data fusion applications, may be designed and finally brought to an automotive
ECU. The hypothetical system uses a sensor which is connected via CAN bus.
Model-based development
As the name indicates, model-based development uses models, i.e. abstract
representation of knowledge. Simple examples for such models are PID controller or
state machines, which are configured to solve a certain problem. Pure model based
development utilizes tools like Simulink [1]. However, algorithms for sensor data
fusion for ADASs often include the perception of the environment. Prominent example
are multi object trackers (MOT), usually implemented by Bayes filters. One example
for that would be a bank of Kalman filters with existence estimation and measurement
association. Such systems offer many degrees of freedom in their design, as system
and measurement state and models may be chosen. They are therefore very complex
to handle in a model-based approach.
Figure 4 illustrates typical set-ups involved in the model-based development process.
Usually, logging tools (e.g. Vector CANalyzer [2]) are used to provide sensor data from
a test vehicle (Set-up M1). This data is used for offline playback algorithm design in a
model-based
development
environment
like
Simulink
(Set-up
M2).
If
the
Set-up M1
Recording of sensor data
Data
recorder
CAN reader
Sensor
data
Offline data
player
Set-up M2
Playback of sensor data
Development of algorithms
Algorithm
Algorithm
Feedback from
the real-world
Set-up M3
Test of algorithms during
their development
CAN writer
CAN bus
Vehicle-under-test
CAN Reader
i/f
Algorithm
i/f
(C-code)
Set-up M4
Validation of the system
CAN writer
CAN bus
CAN bus
Vehicle-under-test
Coding-based development
The opposite of that is a pure coding-based approach, which is illustrated in Figure 5.
In that case the system is implemented in a high-level framework, usually given by
C++, C#, Java, or MATLAB [4] libraries (Set-up C1). However, even if supporting
software libraries or other code may exist in that case, in general the whole
complexity of the models needs to be handled by the programmer.
CAN reader
CAN data
CAN data
CAN writer
Data player/
recorder
PC-based high-level software framework
CAN bus
CAN bus
Vehicle-under-test
Manual re-implementation of
algorithm and interface (i/f)
CAN reader
CAN data
i/f
Algorithm
CAN data
i/f
(C-code)
CAN writer
Data player/
recorder
PC-based high-level software framework
CAN bus
Set-up C1
Recording of
sensor data
Playback of
sensor data
Development of
algorithms
Test of
algorithms
during their
development
Set-up C2
Playback of
sensor data
Test of
algorithms
code
CAN bus
Vehicle-under-test
Manual transfer of
algorithms code
CAN Reader
i/f
Algorithm
i/f
(C-code)
Set-up C3
Validation of the
system
CAN writer
CAN bus
CAN bus
Vehicle-under-test
An advantage is that C, C++ and C# offer efficient ways to access hardware of sensors.
Examples for such frameworks are ADTF [5], BASELABS Connect [6], or RTMaps [7].
Aim of the algorithm development process is (C-)code running on an automotive ECU.
For that reason, the code from set-up C1, yielding efficiency of development time
using high-level languages, needs to be transformed to that representation, as
features like using runtime-polymorphism of object oriented programming or
dynamic memory allocation are commonly not permitted by the MISRA standard used
for automotive ECU. Additionally to the manual re-implementation of the actual code
of the algorithm, even the environment-specific interfaces need to be implemented.
Those interfaces transform the data from a level of separate scalar signals (e.g.
radar-target 1, azimuth value in rads) on the CAN bus (for example given by a
dbc-file) to a data structure representation which can be used by the algorithm code.
www.baselabs.de | info@baselabs.de | +49 371 3371 51 10
development and test time can be reduced significantly. In addition, the interface
generation is not limited to BASELABS Connect. The code and configuration
generation can be adopted not only to other high-level rapid prototyping frameworks,
but also to such frameworks targeting automotive ECUs such as AUTOSAR.
Sensor data
Algorithm (C#-Code)
CAN reader
Data player/
recorder
In-House-Framework
Set-up H1
Recording of
sensor data
Playback of sensor
data
Development of
algorithms
Test of algorithms
during their
development
Result
CAN writer
Automatic generation of
C-code und interfaces
Display
Algorithm (C-Code)
ADTF
CAN bus
Vehicle-under-test
CAN reader
Set-up H2
Validation of the
system
CAN writer
Algorithm (C-Code)
ECU
CAN bus
CAN bus
Vehicle-under-test
By using the hybrid-development approach not only the given advantages for a
high-level prototype are exploited, the approach also enables:
1. The use of the same code in high-level prototype and ECU system
2. Quick changes of ECU code even in complex ADAS algorithm architectures
3. Reduced system development time
both
model-based
development
and
coding-based
development
are
successfully used in the practical development of automotive software, they both have
specific advantages and disadvantages. In the following, the flexibility in design and
10
Development
Transition to
Development
approach
series system
Flexibility
Algorithm
Sensor
support
interface
fusion
Direct ECU
implementation
Coding-based
Model-based
Hybrid
Not necessary
Manual reimplementation
Template-based
code generation
Novel code
generation
via
long
very low
none
ECU; direct
long
low
none
PC; direct
medium
low
limited
short
high
full
additional
hardware
PC; direct
11
System/State
MATLAB R2013a
BASELABS Create
Linear
Linear
transition model
Space
Representation
Non-linear
Vector of floating point
numbers
Bayes filter
Kalman filter
implementations
Kalman filter
Extended Kalman filter
Unscented Kalman filter
Particle filter
Build-in models
Linear
Linear
Non-linear and automotive specific
While one single filter is of course suitable to track only one target at the first stage,
additionally functionality is added to the algorithmic system to estimate the states of
multiple objects. That contains basically the association of particular measurements
from the sensors to certain tracks as well as the evaluation of the existence of tracks.
Furthermore, as real-world sensors are not perfect, clutter needs to be modelled as
12
Measurement
Association Algorithms
MATLAB R2013a
BASELABS Create
Hungarian
assignment
(Complexity O(n))
Existence Estimation/
(Complexity O(n))
Multiple local nearest neighbor (O(n))
Sequential Probability ratio Testing
Clutter Handling
(SPRT)
-
Supporting
functionality
Gating
-
Detection models
Persistence models
13
MATLAB R2013a
Number of sensors/
measurement models
Track-to-Track fusion
1
-
Sensor field-of-view
BASELABS Create
Arbitrary
Covariance intersection
Different field-of-views of multiple
support
sensors including
-
o Overlapping regions
o Non-overlapping regions
o Region dependent detection and
persistence models
Table 4: Available tool-support on ADAS-specific data fusion systems using multiple sensors
Conclusion
Although the development of ADAS systems is specific in terms of the system
components (e.g. the sensors and ECU used in the system), the signal processing
algorithms for ADAS are system-independent on a mathematical level. To benefit
from this inherent independency, the underlying architecture needs to be sufficiently
generalized. Then, the algorithm development can be supported by the right tools.
The BASELABS tools focus on the automotive sector and provide domain specific
models and functionality. That is, data logging and handling on the one side as well as
comprehensive support by BASELABS Create in the development of the actual
algorithms for the data fusion, as it is based on a generalized architecture.
Each BASELABS tool can be used on its own to support engineers and developers
during particular process stages. The combination of the tools yields a unique
end-to-end chain from high-level algorithm and perception model design down to an
automotive ECU. In the hybrid approach, less development and implementation
set-ups are required compared to the other approaches. This in turn may significantly
decrease development time and error-proneness and at the same time increase the
users flexibility as well as the overall system quality.
14
References
1. The Mathworks (2014), Simulink Simulation and Model-based Design,
http://www.mathworks.com/products/simulink/, last accessed 2014/01/14
2. Vector Informatik GmbH (2014), CANalyzer,
http://vector.com/vi_canalyzer_en.html, accessed 2014/01/14
3. dSpace GmbH (2014), dSpace MicroAutoBox,
http://www.dspace.com/en/inc/home/products/hw/micautob.cfm, accessed
2014/01/14
4. The Mathworks (2014) , MATLAB The Language of Technical Computing,
http://www.mathworks.com/products/matlab/, last accessed 2014/01/14
5. Elektrobit Cooperation (2014), Elektrobit: driver-assistance : EB Assist ADTF,
http://automotive.elektrobit.com/home/driver-assistance-software/eb-assist-a
dtf.html, accessed 2014/01/14
6. BASELABS GmbH (2014), Products BASELABS, http://www.baselabs.de, accessed
2014/01/14
7. Intempora S.A. (2014), RTMaps Overview,
http://www.intempora.com/rtmaps4/rtmaps-software/overview.html, accessed
2014/01/14
8. Sebastian Thrun, Wolfram Burgard, Dieter Fox, Probabilistic Robotics, MIT Press
2005
15