2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20,

2017, India

A strategy and framework for analysis of

operational data of automotive radars for
development of Active Safety systems
Manu Vyas Sarath H Smitha K Bagubali A
PG Student, SENSE, VIT Software Engineer, Active Safety, Radar Systems Engineer, Active Safety, Assistant Professor,
University,Vellore Delphi Technical Center India, Delphi Technical Center India, SENSE, VIT
manuvyas710@gmail.com Bangalore Bangalore University,Vellore
sarath.h@delphi.com Smitha.Chandrasekhar@delphi.com bagubali@vit.ac.in

Abstract – With the introduction of radars in the automotive
domain, the automobile, as a product, has evolved greatly.
Modern automobiles are highly advanced. Part of this
advancement are the Active Safety (AS) systems and Advanced
Driver Assistance Systems (ADAS). These systems work byiii.
gathering information about the vehicle’s surroundings and
processing them at a high speed. The main component of such
systems is the automotive radar. Development of such systems
poses a formidable challenge due to the complexity of the
technical design and engineering involved; influenced by
stringent quality assurance, reliability and safety standards.
With the aim to alleviate some burden of development and
improve the time-to-market, the following paper presents a
strategy and a framework to analyze operational data from
automotive radars. The paper illustrates the details of the
approach in Hardware-in-the-loop (HIL), Software-in-the-loop
(SIL) and real-world environments, while comparing with the
conventional strategy. The paper enlists the advantages and
disadvantages of using this approach. It also suggests methods
to increase the speed of analysis.
Keywords— Embedded systems, Automotive embedded
systems, Automotive technology, Automotive Radars, V-Cycle,
Radar Analysis, Simulation, Re-simulation.
I. INTRODUCTION
The modern automobile is essentially a large system
containing a collection of interacting sub-systems. Each of
these sub-systems performs a certain task and makes its
contribution to the overall working of the automobile.
Therefore when we consider the task of development of any
such system, we employ the ‘Systems Approach’[1][3].
With regard to automobiles, most embedded systems
contain the following components[1][2][3][5]–
i. The embedded hardware -
The hardware consists of various components like the
Electronic Control Unit (ECU),memory, sensors, actuators,
feedback loops, loads and wiring.
ii. The embedded software –
The software consists of components like the bootloader
code, power-on-self-test (POST) code, sanity and integrity
checking codes and the main application code.
The environment –
The environment is what the embedded components will
interact with. This will consists of components like
temperature, vibration, humidity, dust, objects on the road,
other vehicles, user inputs etc.
Embedded Components in an automotive system –
The working of the embedded
components(hardware and software) in question can be
summarized in the following 3 steps –
i. Data acquisition (input)
ii. Processing
iii. Generating the result (output)
This may or may not be a cyclic looping process and may or
may not feature a feedback mechanism. Generally the
outputs are stored to a memory for later reference.
Fig 1. An Embedded System
There is a specific requirement in the automotive domain:
the embedded components in question are almost certainly
required to work in real-time. This poses a significant
challenge. In order to meet this requirement, the components
need to be engineered in such a way that the act of
processing the information takes the minimum time[3].
Optimization can be done on all fronts of the embedded
components. For example - Optimization of hardware
would refer to solutions that reduce signal propagation delay

978-1-5090-3704-9/17/$31.00 © 2017 IEEE

2176
2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20, 2017, India
and higher-capacity physical layer standards. Optimization
of software would refer to solutions that improve memory
usage and/or generate results more quickly i.e. a lower
process turnaround time.
II. LITERATURE REVIEW
A. Active safety and advanced driver assistance systems
in automobiles –
In order to increase the safety and convenience of
those inside the vehicle as well as those outside the vehicles
in some cases, AS and ADAS systems have been developed.
These systems utilize the aforementioned embedded
components to perform certain functions. Most modern
vehicles can be installed with cameras and radars. A
schematic is shown in the following figure.
Fig 2. A modern automobile with radars and cameras
Cameras and radars are advanced sensors which can
generate a lot of information. By combining their
information through a process called ‘Sensor fusion’[4], it is
possible to create many ADAS features.
Fig 3. Sensor Fusion
Some common ADAS features[5] are Adaptive Cruise
Control (ACC), Autonomous Emergency Braking (AEB),
Collision Warning (CW), Lane Departure Warning (LDW),
Lane Keep Aid (LKA), Blind Spot Information System
(BLIS) etc.
B. Challenge in developing AS and ADAS features –
The development of such features requires a lot of
resources. The general flow of development is based on the
2177
‘V’ cycle method[7][8] and can be described with the
following figure –
Fig 4. The ‘V’ cycle
The challenge in development comes in various stages of
the V cycle. The developers need to meet the requirements
of the Original Equipment Manufacturers (OEMs) on a wide
range of aspects. In a nutshell, the developers need to create
features that are consistently reliable, accurate and precise in
their working.
There are many faults which can occur in an ADAS. There
may be failures in hardware and software components. For
example in the domain of sensors, the image sensor of the
camera can generate issues like dead-pixels. Deformities in
the antenna or vibrations can distort a radar’s beam. The
algorithms of the ADAS features can generate erroneous
results. On the other hand, in the domain of actuators, the
AEB actuator may not recognize a trigger and fail to brake
the car. Then there are more general faults such as breaking
of the electrical connections of the ECUs to the Vehicle
Communication Bus or electromagnetic interference.
The conventional strategy has been described in detail in the
work of Skruch et al. [5]. The proposed strategy is based on
this reference and builds upon the same.
In this paper, the proposed strategy can be used to analyze
and test a wide range of faults. The focus shall be on
embedded software for radars.
III. DISCUSSION
This segment is organized as follows : First, the
conventional strategy and framework of analysis are
described. Then the disadvantages of the same are listed.
Subsequently, the proposed strategy and framework are
described, followed by the advantages (over the
conventional method) and disadvantages. For understanding
purposes, we use the following terms which designate the
common steps in the two methods –
A. Data Collection
B. Data Storage
C. Re-Simulation of Data and Comparative Analysis
D. Reporting
We also use the following terms –
2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20, 2017, India

Local computer : A computer connected to the car which is
usually used to create data logs.
Test bench : A computer placed in the office which is used
to perform testing on test-algorithms and data logs.
Implemented-algorithm: Algorithm which runs on
embedded hardware (ECU).
Test-algorithm: Algorithm which run on a test bench or a
local computer.
1. Conventional strategy and framework –
A. Data Collection –
The radar generates a lot of data based on what it ‘sees’.
This data is fed to implemented-algorithms of the ADAS
features (running in the ECU). They generate responses for
the actuators correspondingly. A local computer is
connected to the system. Using specialized software on that
computer, it is possible to capture all of the raw radar data,
implemented-algorithms’ outputs and a lot of other
information related to the vehicle into ‘data logs’. It is
important to note that due to enormous amount of data being
logged, the size of the logs can become very large very
quickly. The data logging software can divide the data logs
into segments to enable easier handling rather than a
singular ungainly data log. The data logs can be replayed on
the data logging software as well
The actual process of creating data logs can be based on[5] -
1. Real-world Data Acquisition -
Such data is acquired by performing real-world
tests such as test drives/road tests in controlled
environments (test tracks) and uncontrolled
environments (public roads and highways as well
as well as off-road).
2. Virtual Data Acquisition –
Such data is acquired by performing hardware-in-
the-loop (HIL) simulations on a test bench.
A simulated environment for the implemented-
algorithms is created a test-bench computer usually set-up in
the office; based on the idea of software-in-the-loop (SIL)
testing. Modified copies of the implemented-algorithms are
made run on the test-bench. We will call these test-
algorithms. The collected data logs are retrieved from the
repository and fed to the SIL. The SIL extracts the raw radar
data from the data log and feeds it into the test-algorithms.
The test-algorithms generate their outputs, just like the
implemented-algorithms. The outputs of the test-algorithm
are recorded. All data is logged again, essentially creating a
‘re-simulated’ copy of the input log.
Once this is done, both sets of logs are analyzed using tools
which help visualize the information stored within the logs.
However, such tools are confined to data representation; not
analysis. Most of the analysis is performed manually by
comparing the data logs.
D. Reporting -
By doing manual comparisons, the developers create
reports and save them for future references. Based on the
reports, the developers make changes in the test-algorithms
and test them again. Once they are satisfied with the results,
they put these algorithms into the vehicle and perform real-
world tests. Eventually, a test-algorithm becomes an
implemented-algorithm and the cycle repeats.

Real-world data is representative of the interaction of the

embedded software with the environment while virtual data
can be used to perform tests on specific features and to
simulate those conditions which are harder to simulate in the
real-world.
Fig 5. The Workflow in the conventional method.
B. Data Storage -

The data is stored in a secondary storage device such as

a hard drive on the local computer or on a server. This data
repository can be used to store and retrieve data logs as per
requirement.
C. Re-Simulation of Data and Comparative Analysis
2178
Disadvantages of conventional method –
1. Time consumption and manual effort -
This method is time consuming. Usually it takes
long time to for the developers to test the data logs and
obtain the results of their interest. Then, it takes time to
2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20, 2017, India
make the changes to the algorithms, apply them to the
vehicle, and do the whole cycle of testing again. The
manual effort involved in this method is large. Data
logs contain a huge amount of information and to
analyze it, a lot of effort is needed. All this increases the
time-to-market.
2. Chances of missing difficult-to-spot issues –
Since the analysis is manually done, the chances of
missing a difficult-to-spot issue are high. Sometimes
the data is there but due to unintuitive representation,
issues are missed. In the long process of development,
such misses can create a snowball effect and later lead
to bigger issues.
2. Proposed strategy and framework –
In the proposed method, we propose the following
changes in the corresponding steps in the workflow of the
conventional method -
A. Data Collection - No modifications.
B. Data Storage -
In the proposed strategy, it is assumed that the radar
data is being segmented every five minutes. The current
segment resides in the analysis framework while it is being
analyzed and then passed onto the server as a fresh five-
minute segment arrives.
C. Re-Simulation of Data and Comparative Analysis -
As previously explained, the local computer used in the
conventional method, is used for collection of data logs. A
separate test-bench is later used to analyze the data logs in
the SIL environment, at a later time. Here is where we
propose a change. We shift most of the SIL and analysis
workload onto the local computer.
On the local computer, which is being used to create the
data logs, we also set-up the SIL environment. The current
five-minute log segment is fed into the SIL which contains
the test-algorithms. All data is logged again, now essentially
creating a re-simulated copy of the current five-minute log
segment. So now, the local computer will be holding onto –
1. The responses of the implemented-algorithms.
2. The responses of the test-algorithms.
2179
Fig 6. Data logs
Both sets of logs are then passed onto the Comparative
Analysis code, which also runs on the local computer. This
code extracts the raw radar data and performs comparisons
based on the outputs generated by the implemented-
algorithms and test-algorithms. The analysis code takes a
sample from the raw radar data and for that sample, finds
the corresponding responses of the implemented-algorithm
and test-algorithm respectively. Then it generates reports
highlighting the differences between the two responses. The
code can be modified to test for specific cases and
conditions as well.
The comparative analysis code performs analysis using two
types of methodologies –
1. Direct comparison of outputs of the two algorithms and
reporting the differences.
2. Performing mathematical operations on the outputs of
the two algorithms and finding out the correlation.
Multi-variable normalized Euclidean distance
correlation method is one common method. Using this,
the differences between the outputs are even more
intuitively understood. Ideally, the developers would
want the outputs to be highly correlated to the OEM’s
specifications.
D. Reporting -
The reports generated for every set of five minute log
segments are stored along with the logs themselves. The in-
car hotspot is used to create a connection to the server using
the cellular network to send the data logs and reports.
The developers can use the report to quickly identify the
highlights which have been observed and make further
modifications to the test-algorithms until satisfactory results
are achieved.
For example, suppose the algorithm for ACC needs to be
analyzed. All feature function algorithms require some
2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20, 2017, India
calibrations. Suppose that the implemented-algorithm is
working on a set of calibrations which are giving some
unsatisfactory results when compared to the OEM
requirements. In an attempt to achieve better results, the
developers change the calibrations to different values which
they believe should produce more acceptable outputs, and
load them in the test-algorithm. Then using the analysis
framework, it can be measured in real-time, if the test-
algorithm has yielded any improvements over the currently
implemented-algorithm.
The schematic of the framework and the workflow is given
in the following figures –
Fig 7. Schematic Diagram
Fig 8. Workflow in the proposed method
IV. RESULTS
Advantages of proposed method –
1. Real-time analysis of algorithms –
2180
The biggest benefit of this method is the ability to
compare and analyze algorithms and data in real-time.
The results and reports are created the instant the data
is processed. This can give a very ‘hands-on’ feel to the
whole process of development.
2. Reduced time consumption and manual effort –
Both time and effort are saved in this method. This
will reduce the length of the development cycle and
also increase productivity.
3. Identifying difficult-to-spot issues –
The reports generated by this method are intuitive
and easy to understand. This will enable developers to
quickly zero-down on issues and solve them.
Disadvantages of proposed method –
1. Securing the connection to the server –
Since we use the in-car hotspot and cellular
network to connect to the server, the connection needs
to be encrypted in order to protect the data logs and
reports.
2. Need for more processing power –
The local computer needs to have a large amount
of processing capacity to be able to run the data logging
software along with the resimulation and comparative
analysis code.
V. FUTURE SCOPE
Certain modifications and additions can be done to the
suggested framework in order to increase the performance.
1. Use of multicore processors and multithreaded code
design in the ECU as well as the local computer to
increase speed of analysis[6].
2. Use of loop parallelization techniques in the code to
increase processor clock utilization[6].
3. Supplying the raw radar data to the implemented-
algorithm and test-algorithm directly and comparing the
outputs. This would by-pass the need to generate data
logs, first for the implemented-algorithm and then again
for the test-algorithm.
VI. CONCLUSION
Development of Active Safety systems is an arduous
process which requires resources. The current strategy for
development bears scope for modifications and
improvements. In this paper, we have proposed a strategy
which can yield benefits on many fronts if implemented. By
using this method, the developers can iterate through the
development cycle more quickly, thereby arriving at better
results faster than by using the conventional strategy. This
2017 2nd IEEE International Conference On Recent Trends in Electronics Information & Communication Technology (RTEICT), May 19-20, 2017, India

strategy will also reduce the time-to-market of the ADAS

features and reduce development costs while increasing
revenues. The developers can benefit from the holistic
nature of the proposed strategy.

REFERENCES

[1]. Kim, H., Fried, D., and Soremekun, G., "Combinatorial Design
Optimization of Automotive Systems by Connecting System
Architecture Models with Parts Catalog," SAE Int. J. Mater. Manf.
7(3):2014, doi:10.4271/2014-01-0319.
[2]. Skruch, P., Panek, M. and Kowalczyk, B., “Model-Based Testing in
Embedded Automotive Systems,” in Model-Based Testing for
Embedded Systems, ed. Zander-Nowicka, J., Schieferdecker, I. and
Mosterman, P.J., 545-575, CRC Press, Taylor & Francis Group, Boca
Raton, London, New York, 2011.
[3]. Patil, S. and Kapaleshwari, L., "Embedded Software - Issues and
Challenges," SAE Technical Paper 2010-01-0669, 2010,
doi:10.4271/2010-01-0669.
[4]. Hammerschmidt, D. and Leteinturier, P., "Automotive Sensors &
Sensor Interfaces," SAE Technical Paper 2004-01-0210, 2004,
doi:10.4271/2004-01-0210.
[5]. Skruch, P., Dlugosz, R., Kogut, K., Markiewicz, P. et al., "The
Simulation Strategy and Its Realization in the Development Process
of Active Safety and Advanced Driver Assistance Systems," SAE
Technical Paper 2015-01-1401, 2015, doi:10.4271/2015-01-1401
[6]. Kareti, V., Ranadive, P., and Vaidya, V., "Parallelization and Porting
of Multiple ADAS Applications on Embedded Multicore Platforms,"
SAE Technical Paper 2015-01-0258, 2015, doi:10.4271/2015-01-
0258.
[7]. M. R. Naeem, W. Zhu, A. A. Memon and A. Khalid, "Using V-Model
methodology, UML process-based risk assessment of software and
visualization," Proceedings of 2014 International Conference on
Cloud Computing and Internet of Things, Changchun, 2014, pp. 197-
202.doi: 10.1109/CCIOT.2014.7062536
[8]. Santos, M., Ambiel, V., Acras, M., and Gliwa, P., "On the Timing
Analysis at Automotive Real-Time Embedded Systems," SAE
Technical Paper 2017-01-1618, 2017, doi:10.4271/2017-01-1618.

2181