Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
Platform System Architecture – 2nd Release
Deliverable n. D25.2 - Platform System Architecture (Second Release)
Sub Project SP2 ADAS development platform
Workpackage WP2.5 Platform System Architecture
Tasks T2.5.1
T2.5.2
Hardware architecture
Software architecture
Authors Frank Badstübner
Ralf Ködel, Wilhelm Maurer
Martin Kunert
André Rolfsmeier
Joshué Pérez
F. Giesemann, G. Paya Vaya,
H. Blume
Gideon Reade
Infineon Technologies AG
Robert Bosch GmbH
dSPACE GmbH
INRIA
IMS
ASL
File name D25.2_Platform_System_Architecture_-
_Second_Release_IFAG_Final
Status Final, v0.5
Distribution Restricted (RE)
Issue date 31/08/2014 Creation date 04/10/2014
Project start and
duration
1st of September, 2012 – 36 months
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 3
of 63 DESERVE Deliverable D25.2
REVISION CHART AND HISTORY LOG
Ver DATE AUTHOR REASON
0.1 2014-05-28 Frank
Badstübner
Table of contents and document structure
created, IFAG contributions and content from
first release integrated
0.2 2014-07-14 Pier Claudio
Antonello
CRF contributions added: Added in 2.1: rapid
prototyping architecture instance in WP4.1
WP4.2 and WP4.3; Added 3.2 Application
Software Modules
2014-07-18 Gideon Reade ASL contributions added
2014-07-24 Hans Deragarden Volvo contributions added
2014-08-25 André Rolfsmeier dSPACE contributions added, chapter 2.1
reviewed
2014-08-26 F. Giesemann,
N. Mentzer,
H. Blume (IMS)
Added evaluation results for ADTF and FGPA
based development
0.3 2014-09-03 Frank
Badstübner
dSPACE and IMS contributions added,
consolidated version generated
0.4 2014-09-24 Frank
Badstübner
Final version generated.
0.5 2014-10-05 Frank
Badstübner
Reviewer comments considered. Final version
generated for submission.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 4
of 63 DESERVE Deliverable D25.2
TABLE OF CONTENTS
REVISION CHART AND HISTORY LOG ....................................................................... 3
TABLE OF CONTENTS ............................................................................................. 4
LIST OF FIGURES .................................................................................................. 6
LIST OF TABLES .................................................................................................... 7
LIST OF ABBREVIATIONS ....................................................................................... 8
EXECUTIVE SUMMARY ........................................................................................... 11
1. INTRODUCTION .............................................................................................. 12
1.1. Objective and scope of this document ..................................................................... 12
1.2. Structure of the deliverable ................................................................................... 12
2. HARDWARE ARCHITECTURE ............................................................................. 13
2.1. Flexible, modular and scalable rapid prototyping platform ......................................... 15
2.1.1. Rapid prototyping architecture for inter-urban assist (WP4.6) ........................................... 17
2.1.2. Rapid prototyping architecture for WP4.1-4.3 ................................................................. 20
2.1.3. Rapid prototyping architecture for ACC with autobrake truck application ............................ 22
2.2. High speed low latency communication bus ............................................................. 24
2.3. Transfer of prototyping functionality into next generation MCU .................................. 28
2.3.1. RADAR HW accelerator (signal processing unit) Simulink model ........................................ 28
2.3.2. Vision pixel preprocessor Simulink model ....................................................................... 31
2.4. Transfer of Prototyping functionality into Next Generation ECU .................................. 32
2.5. FPGA-based platform to emulate hardware modules ................................................. 33
2.6. Testing process for the hardware architecture ......................................................... 34
3. SOFTWARE ARCHITECTURE .............................................................................. 37
3.1. Specification of the software architecture ................................................................ 38
3.2. Application Software Modules ................................................................................ 41
3.3. Concepts for client-server access ........................................................................... 44
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 5
of 63 DESERVE Deliverable D25.2
3.4. Multi-task option to permit adding and removing of functionalities ............................. 47
3.5. Hardware optimized software functionalities ............................................................ 48
3.5.1. Motivation for the DSP library ....................................................................................... 49
3.5.2. Function naming convention ......................................................................................... 49
3.5.3. Calling convention ....................................................................................................... 50
3.5.4. Target Function list ..................................................................................................... 50
3.6. Use of ADTF together with FPGA based development platform ................................... 53
4. CONCLUSION ................................................................................................. 55
REFERENCES ....................................................................................................... 56
ANNEX A ............................................................................................................. 58
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 6
of 63 DESERVE Deliverable D25.2
LIST OF FIGURES
Figure 1: DESERVE approach – use of common platform for all ADAS modules .......................... 14
Figure 2: DESERVE rapid prototyping architecture with three development levels (Level 1: PC
based development frame work, Level 2: Embedded Controller frame work, Level 3:
Dedicated Hardware Accelerator framework) .......................................................... 17
Figure 3: Generic hardware architecture of DESERVE development system ............................... 19
Figure 4: DESERVE rapid prototyping architecture for WP4.6 – inter urban assist ....................... 19
Figure 5: DESERVE rapid prototyping architecture for WP4.1, WP4.2 and WP4.3 ........................ 21
Figure 6: HW platform for in-vehicle test .............................................................................. 21
Figure 7: DESERVE rapid prototyping architecture for ACC with autobrake ................................ 23
Figure 8: ACC with autobrake functional architecture .............................................................. 23
Figure 9: Architecture of an x86 processor based prototyping system ....................................... 25
Figure 10: I/O access with flow control processors ................................................................. 26
Figure 11: Architecture of a high speed low latency bus interface ............................................. 27
Figure 12: RADAR hardware accelerator Simulink model ......................................................... 28
Figure 13: Vision pixel processing model ............................................................................... 31
Figure 14: FPGA-based platform with the DESERVE development system .................................. 34
Figure 15: DESERVE platform architecture ............................................................................ 37
Figure 16: Open CV functions .............................................................................................. 39
Figure 17: OSI seven layer model for computer network communication .................................. 40
Figure 18: Overview on the principles of virtual interaction using the AUTOSAR ......................... 42
Figure 19: DESERVE Platform splitting .................................................................................. 44
Figure 20: External bypassing and client-server communication ............................................... 45
Figure 21: Service based bypassing extended by a concept for client-server access ................... 46
Figure 22: Overview of an exemplary sign detection algorithm ................................................ 53
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 7
of 63 DESERVE Deliverable D25.2
LIST OF TABLES
None
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 8
of 63 DESERVE Deliverable D25.2
LIST OF ABBREVIATIONS
ABBREVIATION DESCRIPTION
ACC Adaptive Cruise Control
ADAS Advanced Driver Assistance System
ADTF Automotive Data and Time-Triggered Framework
AEB Autonomous Emergency Braking
API Application programming interface
ASIL Automotive Safety Integrity Level
AUTOSAR AUTomotive Open System ARchitecture
CFAR Constant False Alarm Rate
CPU Central Processing Unit
CV Computer Vision
EABI Embedded Application Binary Interface
FIFO First In – First Out (equivalent to first come, first served)
FPGA Field Programmable Gate Array
GI Generic Interface
GigE Gigabit Ethernet
HIL Hardware In the Loop
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 9
of 63 DESERVE Deliverable D25.2
HMI Human Machine Interface
HW Hardware
IMS Institute of Microelectronic Systems
ISO26262 ISO 26262 is a Functional Safety standard, titled "Road vehicles --
Functional safety". Functional safety features form an integral part of
each product development phase, ranging from the specification, to
design, implementation, integration, verification, validation, and
production release. ISO 26262 defines functional safety for automotive
equipment applicable throughout the lifecycle of all automotive
electronic and electrical safety-related systems.
IWI Information Warning Intervention
MCU Microcontroller Unit (here with focus on multi-core processors)
NVRAM Non-Volatile RAM
OpenCL Open Computing Language
OpenCV Open Source Computer Vision Library
OSI Open Systems Interconnection (Model)
PC Personal Computer
PIL Processor In the Loop
POSIX Portable Operating System Interface
PWM Pulse Width Modulated
RTE Run-Time Environment
RTOS Real Time Operation System
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 10
of 63 DESERVE Deliverable D25.2
SoC System on Chip
SPU Signal Processing Unit
SW Software
VFB Virtual Function Bus
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 11
of 63 DESERVE Deliverable D25.2
EXECUTIVE SUMMARY
The basic idea and intention of the DESERVE project is to standardize the interfaces
between the three different development levels as far as possible:
Level 1: PC-based development framework
Level 2: Embedded controller development framework
Level 3: Dedicated hardware (e.g. ASIC / accelerator) development framework
Depending on the performance of the PC in best case all or typically only specific parts of
the SW modules are executed in level 1. During the development process more and more
SW parts are transferred to the HW-Accelerator level 3, which, in the final development
stage, results in the next generation embedded ADAS target system.
This deliverable focuses on the overall platform system architecture and addresses
following key hard- and software topics:
Chapter 2 concentrates on the hardware requirements and architecture topics including
the need for a flexible, modular and scalable rapid prototyping platform, the high speed,
low latency communication bus (e.g. Gbit Ethernet), the transfer of prototyping
functionality into next generation MCU (supported by modelling of radar hardware
accelerator and vision pixel pre-processor in Simulink) down to an FPGA-based platform
to emulate the hardware modules, and finally considering the testing process.
Chapter 3 is dedicated to aspects concerning the software architecture of the platform
system. The software architecture is defined, concepts for client-server access are
described, a multi-task option to permit adding/removing of functionalities is presented.
Additionally, the way to achieve hardware optimized software functionalities is proposed
(including the use of DSP library and the agreement on naming and calling conventions).
Finally, the use of the ADTF platform (from level 1 down to FPGA level 3) is explained.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 12
of 63 DESERVE Deliverable D25.2
1. Introduction
1.1. Objective and scope of this document
The objective of this deliverable is to describe the second release of the platform system
architecture. D25.2 is the first of a series of deliverables documenting the work per-
formed to define the second release of the platform system architecture serving as the
processing platform for ADAS systems:
D25.2 Platform system architecture – 2nd release
D25.4 Standard interfaces definition – 2nd release
D25.6 Guidelines for applications – 2nd release and
D25.8 DESERVE platform – 2nd release
1.2. Structure of the deliverable
D25.2 covers the different relevant hardware architecture aspects (chapter 2 refers to
task 2.5.1) and software architecture aspects (chapter 3 refers to task 2.5.2) of the
platform.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 13
of 63 DESERVE Deliverable D25.2
2. Hardware architecture
DESERVE has to be flexible enough to be implemented in a distributed and scalable
architecture (several modules, each of them able to sense and/or process and/or
actuate) or a concentrated one (sensors and actuators all linked with a single unit of
processing and control). Task 2.5.1 identifies which conditions have to be satisfied by the
individual subsystem architectures in order to be compliant with the DESERVE generic
hardware platform. For maximum reusability the DESERVE concept and hardware
architecture has to be designed in such a way that subsystems of different generations
(or respectively the kernels of it) can be used in parallel, thereby enabling the rapid and
effective creation of next-generation innovative ADAS systems by using well tested and
certified kernel functions of the “old” system which partly could be already implemented
as SoC (System on Chip). The DESERVE development platform can be seen as a flexible
rapid-prototyping environment that enables fast and efficient development of next-
generation ADAS functions in a continuous iteration cycle between the current and next-
generation embedded subsystem components.
Furthermore, the DESERVE concept has to be flexible enough for different DESERVE
partners to make different implementations. These would be of forms that might in
future be interoperable, although DESERVE will not attempt to define detailed standards
which would be necessary for actual interoperability.
The main DESERVE idea concerns the use of one common platform system (Figure 1) for
all ADAS functional modules, instead of the current approach to have one platform for
each individual ADAS system. Basically, three main hardware architecture challenges
arise from this idea:
Automotive quality: The platform needs to provide high reliability over the
complete automotive temperature range, power supply and environmental
conditions. As ADAS systems address safety aspects, the platform should
implement as far as possible the ISO 26262 requirements, i.e. at least the
hardware components that are near to the final product unit shall support the
required ASIL level.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 14
of 63 DESERVE Deliverable D25.2
For PC-based platform components the typical commodity specifications shall be
reached as a minimum and, where possible, extended requirements should be
applied.
Figure 1: DESERVE approach – use of common platform for all ADAS modules
Possibility to extend hardware capabilities: The platform needs to be designed up-
front to support the possibility to include additional hardware into the system.
Standard sensor interfaces are needed, for instance, but also standardized
interfacing to external FPGA/DSP for performance enhancement is required. For
scalability purposes, such external devices need to be cascadable. Similar consi-
derations hold for the memory interface capability.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 15
of 63 DESERVE Deliverable D25.2
A special case of hardware extension capabilities is the reuse of serial parts from
earlier generations to speed up the development process or to increase the sensor
perception by placing more sensors on the car.
Finally, a seamless environment tool chain is needed. One key requirement lies in
the reuse of the existing tool ecosystem over several platform generations.
Further, we should target adaptability of the tools to the broad industry use cases,
e.g. next generation video and radar sensors. Additionally, real-time monitoring
and debugging of interface and processing for development purposes represent
key challenges.
Although the DESERVE objective is a “common platform”, for the actual implementations
within the DESERVE timescale, there are multiple possible implementations. These draw
from the same concepts, and to some extent a common “parts bin”, but in DESERVE’s
timescale each will only support interoperability within some collaborating subgroup.
These are roughly grouped around demonstrators, e.g.:
Daimler/Bosch/Infineon/dSPACE – Inter-urban assist (WP4.6)
CRF/Inria/Intempora – Warning functions (WP4.1), control functions (WP4.2) and
vulnerable road user protection functions (WP4.3)
Volvo/ASL/Intempora – ACC with autobrake truck application (a DESERVE
interface is needed at the interface between ASL’s Perception Platform
implementation, and Volvo Truck’s Application Platform).
Other non-demonstrator partners
2.1. Flexible, modular and scalable rapid prototyping platform
The DESERVE development platform architecture needs sufficient flexibility, modularity
and scalability to cope with the steadily increasing complexity and calculation power
request of the high-sophisticated algorithms of the perception, evaluation and reasoning
modules. The fundamental challenge lies in the demanding antagonism to provide more
and more calculation power in always shorter time, with the boundary condition of
maximum reuse of the preceding generation concepts and hardware components.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 16
of 63 DESERVE Deliverable D25.2
The basic requirements for the architecture of the DESERVE rapid prototyping platform
can be expressed in the following bullet points:
1) Enough flexibility to encompass different development environments in a com-
mon, seamless framework for both the high-level algorithm development and the
easy porting of these SW modules to the embedded target platform.
2) Real time recording and playback capabilities for both the high-level and
embedded system implementations.
3) A communication architecture that is capable to shift SW portions from the high-
level development side to the embedded target system as required (i.e. bypassing
with HW accelerators).
4) A seamless interoperability and replacement between the high-level (i.e. PC-
based) and embedded target systems both for development and validation
purposes.
It is obvious that many of the demanding algorithms cannot be run in realtime on a
universal PC-based platform, because several data streams with Gigabit transfer-rates
from video and radar sensors have to be processed. For this task dedicated hardware
accelerators have to be used to squeeze down the information flow to a manageable
dimension. The programming of such dedicated hardware components is still burdensome
due to a lack of efficient, automatic coding tools. This is in strong contradiction to the
typical research and development process, where in the start-up phase the software code
is still in an early experimental stage with many changes and software parts that are
sometimes completely off the track. In this software pioneering phase the expensive
hand-coding of very specific one-time code is unproportional and difficult to justify.
The compromise can be found in a compound approach where for each part in the pro-
duct development cycle the appropriate measures are available. For research and early
product development well-established software tools like Matlab/Simulink™ or ADTF are
available. What is missing is the development framework for seamless transition from
high-level software tools to very specific hardware coders for embedded systems.
The idea and intention of the DESERVE project is to standardize the interfaces between
the three different development levels as good as possible:
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 17
of 63 DESERVE Deliverable D25.2
Level 1: PC-based development framework
Level 2: Embedded controller development framework
Level 3: Dedicated hardware (e.g. ASIC) development framework
As the platform is intended to be flexible, it should also be able to work with variations
on this hardware progression.
2.1.1. Rapid prototyping architecture for inter-urban assist (WP4.6)
The three development levels are shown in Figure 2 for the DESERVE demonstrator inter-
urban assist (WP4.6).
Figure 2: DESERVE rapid prototyping architecture with three development levels
(Level 1: PC based development frame work, Level 2: Embedded Controller
frame work, Level 3: Dedicated Hardware Accelerator framework)
Inputs from proprietary ADAS sensor systems and information sources are analyzed and
sent via a generic interface GI1 to the PC based development environment. Here the
PC based
development
framework
WIN7 / Matlab&
Visual C++
Embedded
Controller
framework
dSPACE RCP /
TargetLink&VHDL
HW
Accelerators
dedicated ASICs (e.g. from last generation or
newly designed)
GI2
GI3
ADAS Inputs:
Radar Sensor
NIR Camera1
NIR Camera2
Navigation
Breakout Box
GI1
CAN
LVDSLVDSCAN/ADASISV2
PI1-4
Legend: PI = private interface GI = generic interface RCP = Rapid-Control-Prototyping LVDS = low voltage differential signal
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 18
of 63 DESERVE Deliverable D25.2
ADTF tool with its filter programming concept is used to develop or improve SW modules
on a high-level programming language with lowest programming effort and in shortest
time. RTMAPs could represent a suitable alternative. For the WP4.6 demonstrator part-
ners involved agreed to work with ADTF.
The partitioning and optimization of parts of the SW modules is consecutively done by
shifting such portions over the generic interface GI2 to the embedded controller frame-
work that is already much nearer to the final commercial product. Via this bidirectional
interface bypassing techniques like PIL (embedded Processor In the Loop) can be
realized.
In a final step, dedicated HW accelerators can be linked in via the generic interface GI3
by applying the same bypassing concept again. Especially computationally intensive tasks
can so be “outsourced”, so that even the PC-based platform is capable to keep the strin-
gent real-time constraints.
Depending on the performance of the PC in best case all or typically only specific parts of
the SW modules are executed in level 1. During the development process more and more
SW parts are transferred to the HW-Accelerator level 3, which, in the final development
stage, results in the next generation embedded ADAS target system. In this last develop-
ment step, the level 1 (PC) and level 2 (embedded Controller) platform will only serve as
a shell to keep up the overall development framework. Already existing components from
former ADAS generations may be re-used in the early development phase as hardware
accelerators for computational intensive calculations. Mainly standard algorithms that are
fixed and obtain no further modifications over time are preferred candidates for such
specific accelerator implementations.
The generic hardware architecture developed in WP2.1 is shown in Figure 3. This archi-
tecture reflects the three development levels described above.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 19
of 63 DESERVE Deliverable D25.2
Figure 3: Generic hardware architecture of DESERVE development system
In Figure 4 the hardware architecture concept for level 1 (PC-based) and level 2 (embed-
ded controller) development stages for the inter-urban assist demonstrator of WP4.6 is
sketched.
Figure 4: DESERVE rapid prototyping architecture for WP4.6 – inter urban assist
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 20
of 63 DESERVE Deliverable D25.2
The importance of well-defined and standardized interfaces between the particular com-
ponents and modules is striking. For the high speed interfaces GI1, GI2 and GI3 (see
Figure 2) Gigabit Ethernet (GigE) is the preferred candidate. Special interface hardware
boxes for connecting proprietary (sensor) interfaces to already standardized communica-
tion protocols are sometimes needed.
2.1.2. Rapid prototyping architecture for WP4.1-4.3
In Figure 5, the hardware architecture concept for level 1 (PC-based) and level 2 (em-
bedded controller) development stages for the passenger car demonstrator and WP4.1,
WP4.2 and WP4.3 is shown.
The following functions will be developed and integrated in the DESERVE platform: AEB
pedestrian, AEB inter-urban, driver distraction, driver intention. These applications are
partially based on already existing sensors and partially on new generation one’s. All
sensors are acquired by powerful and flexible PC based hardware. The common rapid
prototyping tool for development of the perception platform and the data fusion is
RTMaps. But the platform also includes an embedded controller (MicroAutoBox) where,
during development, high level application software, vehicle control models and HMI
manager (IWI) will be transferred and tested. PC (Level 1) and microcontroller (Level 2)
are connected by Ethernet bus. Currently, the use of Level 3 (Dedicated Hardware
Accelerator) is not foreseen, even if the HW platform includes FPGA board for future
developments (Figure 6).
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 21
of 63 DESERVE Deliverable D25.2
Figure 5: DESERVE rapid prototyping architecture for WP4.1, WP4.2 and WP4.3
Figure 6: HW platform for in-vehicle test
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 22
of 63 DESERVE Deliverable D25.2
2.1.3. Rapid prototyping architecture for ACC with autobrake truck
application
The commercial vehicle demonstrator will be based on collaboration of Volvo, ASL and
Intempora.
A variation on Figure 4 is to push the use of ADTF or RTMaps further across the system.
This further standardizes the interfaces between the boxes (to a higher level in the
protocol stack). This is feasible where the “HW Box (supplier proprietary)” above
supports a Linux kernel, as for RTMaps at least, the middleware runtime can then be run
at the sensor units. Sensors with Ethernet are allowed, but not running the middleware
runtime, to participate in the middleware’s external protocol: In such cases the sensor
would appear in Figure 3 as a separate ADTF filter or RTMaps component, rather than as
an input to a composite one. One of these two approaches is intended for the Volvo
Trucks demonstrator.
This system (Figure 7) is to be composed using two of the three hardware platforms
listed above. ASL will be using, effectively, a production ECU, whereas Volvo will be using
a combination of automotive computers. These will be interconnected using Ethernet as
the low level transport, with RTMaps as middleware. ASL’s preferred approach would be
to actually run the RTMaps runtime on the ASL ECU (which runs Linux); this would mean
ASL did not even need to know what level of Ethernet protocol RTMaps used. However,
time may not permit this, and ASL will probably have to produce a simple protocol com-
ponent on the ECU, which can connect to the RTMaps Ethernet interface on Volvo’s PC.
The data form and content of the data passed from ASL’s virtual sensor to Volvo’s appli-
cation would be a one-off separate partial DESERVE interface, along the lines discussed
in WP25.4 specification. It would be expected to be approximately similar to Daimler /
Bosch’s interface, but not actually compatible as DESERVE partners are not generally
sharing down to a low enough level to do that. The functional architecture for this, the
ACC with autobrake demonstrator, is depicted in Figure 8.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 23
of 63 DESERVE Deliverable D25.2
Figure 7: DESERVE rapid prototyping architecture for ACC with autobrake
Figure 8: ACC with autobrake functional architecture
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 24
of 63 DESERVE Deliverable D25.2
2.2. High speed low latency communication bus
As outlined in chapter 4.4 of [12] the performance of the internal communication bus to
interface the processor and the associated I/O units is essential for a universal develop-
ment platform. Figure 9 illustrates the proposed architecture for an x86 processor based
prototyping system.
The following requirements have to be addressed by the communication bus:
Short latency times (in the range of a few microseconds) associated with the com-
plete processing sequence consisting of capturing input signals by an I/O unit,
triggering the associated processing task on the x86 processor and writing the
resulting output signals by the same or another I/O unit
Latency times are virtually independent of the number of input and output chan-
nels
High data throughput (in the range of one Gbit/s)
No limitation by the bus architecture concerning the number of I/O units which
can be connected to the x86 processor
Time synchronization of I/O units accurate to about 0.1 microseconds so that the
associated data is captured and output exactly at the same point of time
Event synchronization of I/O units allowing input data to be sampled and outputs
to be written exactly at the same event, e.g., at the same crankshaft angle
accurate to 0.1 degrees
Support of up to 16 individual real-time tasks per I/O unit
Option to connect I/O units in a centralized and decentralized way and to bridge
distances of tens of meters
High noise immunity of the communication bus
Support of single and block read/write access
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 25
of 63 DESERVE Deliverable D25.2
Figure 9: Architecture of an x86 processor based prototyping system
At first sight, PCI Express (PCIe, [13]) might be the communication bus of choice when
using x86 processors. However, several requirements listed above are not directly met
by PCIe. Instead, a new high speed communication bus is proposed for a modular
DESERVE platform.
Figure 10 illustrates the typical flow of data related to a real-time task in which I/O units
are accessed. In common prototyping scenarios several of these tasks, timer and/or
event-driven, run in parallel. The software modules mentioned in this figure stand for
dedicated sub-systems of the associated simulation model. To guarantee consistent data
it is essential that all inputs are read (RI) and all outputs are written (WO) exactly at the
same point of time no matter at which positions the respective I/O blocks are used in the
model and how many and what kind of I/O units actually are accessed. Research work
has shown that a dedicated “flow control processor” is required for this allowing I/O
specific code to be executed.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 26
of 63 DESERVE Deliverable D25.2
Figure 10: I/O access with flow control processors
The I/O access with the flow control processor is described in the following:
1. A timer or an external event triggers both a task on the x86 processor and the I/O
program on one or multiple I/O units exactly at the same time (1).
2. The I/O program reads the input data and sends matching data packets via the
communication bus to the processor.
3. During the calculation of software module 1, output data is send via the commu-
nication bus to program 2.
4. At the end of software module 1, an output event TO is generated causing the
program 2 to write all I/O outputs at once (2).
5. The steps 3 and 4 recur with software module m and output event (3) triggers
program 3
The program 1, 2 and 3 may run on the same flow control processor as I/O data is
processed sequentially in the corresponding real-time task.
Further details about the new communication bus are shown in Figure 11 (“network” to
connect architecture levels 1 and 2 presented in Figure 2). The flow control processors
are implemented in an FPGA allowing multiple instances to operate completely in parallel.
This way, for example, a rising edge of a PWM signal can be used to trigger data cap-
turing via ADCs without burdening the x86 processor.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 27
of 63 DESERVE Deliverable D25.2
Figure 11: Architecture of a high speed low latency bus interface
The major part of the conceptual design was the specification of the flow control proces-
sor in the FPGA and of a reduced instruction set to meet the demanding performance
goals.
This reduced instruction set is listed below:
Input / Output Operation
LOAD sX3, {cY32, sY3} (load constant or register into register)
INPIO sX3, aY30 (read word from I/O address to register)
INPMEM sX3, aY13 (read word from memory address to register)
OUTPIO sX3, aY30 (write register content to I/O address)
OUTPMEM sX3, aY13 (write register content to memory address)
Logical Operation
AND sX3, {cY32, sY3}
OR sX3, {cY32, sY3}
XOR sX3, {cY32, sY3}
Basic Arithmetic
{ADD,SUB} sX3, {cY32, sY3}
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 28
of 63 DESERVE Deliverable D25.2
{SHR,SHL} sX3, {cY32, sY3}
Advanced Arithmetic
MUL{HI,LO} sX3, {cY32, sY3}
Program Control
JMP cX10
JMP{Z,NZ} cX10
JMP{C,NC} cX10
NOP
COPY Operation
MEMCPY n8, aX30, aY13 (copy n words from I/O [aX] to memory [aY])
2.3. Transfer of prototyping functionality into next generation MCU
Infineon is developing a Simulink model to implement two numerically intensive algo-
rithms on next generation multi-core micro controller units (MCU), e.g. AURIX platform.
The focus is based on smart hardware acceleration of RADAR (see details in 2.3.1) and
Vision (see 2.3.2) sensor signal processing algorithms. Next generation MCUs represent
hardware accelerators corresponding to architecture level 3 presented in Figure 2. Their
use will allow an optimized overall system set in terms of power consumption and size.
2.3.1. RADAR HW accelerator (signal processing unit) Simulink model
Figure 12: RADAR hardware accelerator Simulink model
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 29
of 63 DESERVE Deliverable D25.2
a) Simulink Model Project description
The main goal is to design a Simulink model of the Radar Signal Processing Unit
for AURIX1 in order to:
enable customer activities, e.g. evaluation of CFAR (constant false alarm
rate) algorithms, advanced prototyping by running a model in a PC and
demonstration
enable internal activities including IP specification verification for designers
and subcontractor
b) SPU Simulink model deliverable
The model of the signal processing unit (SPU) will be provided as an encrypted “s-
function” to enable executable demonstrations.
c) SPU Simulink model milestones
Two steps are introduced to monitor progress:
step1: IP Simulink model development
step2: demo software within Simulink
1 AURIX™ is Infineon’s new family of microcontrollers serving the needs of the automo-
tive industry in terms of performance and safety. Its multicore architecture, based on up
to three independent 32-bit TriCore™ CPUs, has been designed to meet the highest
safety standards while increasing the performance at the same time. Using the AURIX
platform, automotive developers are able to control powertrain, body, safety and ADAS
applications with one single MCU platform. Developments using AURIX will require less
effort to achieve the ASIL-D standard than with a classical Lockstep architecture. Custo-
mers are now able to cut down their MCU safety development. By the same token, a
performance surplus allows for more functionality and offers a sufficient resource buffer
for future requirements, keeping the power consumption on the single-core microcon-
troller level.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 30
of 63 DESERVE Deliverable D25.2
d) Model scope
The scope of the model is to simulate computations and the data produced by
RADAR Signal Processing Unit. There is no intent to simulate execution and trans-
fer times.
e) Model principle
The principle of the model is to generate results in the form of data sets (or data
structures). To allow verifying the behavior of various IPs the data set granularity
should be per IP. So, when starting a new acquisition sequence, the data
structures are initialized. Then, during the acquisition sequence, the data sets are
generated and/or updated according to the command and the processing step.
f) Safety aspects
The model is intended to be used at early stages of customer projects. It is not
intended to be used as reference model for non-regression testing of production
SW.
g) Model verification
The model is being designed at Infineon. It is proposed that the verification is
conducted in Infineon to have independent verification. Customer delivery should
be done only after verification.
RADAR signal stimuli: It is proposed to use data collected using an already avail-
able 77GHz RADAR demonstrator.
Test cases: dedicated use cases should be done per possible SW configuration.
h) Executable demo
The analysis of the project is showing that additional Simulink blocks will be
required to generate stimuli to the RADAR SPU. One identified additional block is
the RADAR State Machine that is generating a ramp index and the antenna index
to the RADAR SPU.
MCU/CPU model: It is not intended to model the TriCore or AURIX. At the end, the
TriCore is executing C code and this is what needs to simulated.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 31
of 63 DESERVE Deliverable D25.2
2.3.2. Vision pixel preprocessor Simulink model
The Pixel preprocessor is made of different execution units in parallel where each of them
can be enabled /disabled, has its own output FIFOs and address range into the shared
video memory (the “EMEM”) and runs from the system clock (up to 300MHz). Main pur-
pose is to enable specific pixel processing to reduce performance and RAM requirements
to enable reduced power consumption and heat anticipation.
Figure 13: Vision pixel processing model
The key features are:
Image region extraction
o Up to 5 user run-time defined regions
o 1 secondary path allow MJPEG compression without CPU load
Configurable down-sampling for main path
M-JPEG compression unit (no CPU load)
Integrated safety watchdog
o Monitoring of SYNC signals from sensor
Powerful memory interface
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 32
of 63 DESERVE Deliverable D25.2
o Each path has its own buffer and its own interrupt
o DMA interface to main RAM
Full debug support from any path
o Selected path can be copied to debug interface
o CRCs protecting payload and header information
2.4. Transfer of Prototyping functionality into Next Generation ECU
Some ADAS ECUs will be expected to run multiple ADAS functions at the same time.
These ECUs can deploy relatively powerful & flexible operating systems so that produc-
tion systems can dynamically switch features on and off according to the driver’s require-
ments. Effectively, they can be like a node of almost desktop-like flexibility, within the
vehicle, but on a production vehicle completely isolated from the rest of the world except
for a tightly controlled AUTOSAR gateway. With no or little change to production builds
they well support, in particular, Ethernet. These production, or slightly enhanced, ECUs
can be deployed as a development platform, either singly, or in an array.
These platforms are also very capable of running basically the same ADAS function
implementations in C/C++ as laboratory PCs. Ideally, such a development hardware can
directly run the runtime environment of ADTF or RTMaps. Less optimally, it can interface
to their public interfaces.
In a production vehicle, these ECUs are expected to run multiple ADAS functions concur-
rently and at full vehicle speed. For development each ECU can run a reduced load, of
one or a few, non-concurrent functions. Functions under test can therefore be less
optimized and with extra test features. Communication between ECUs in this arrange-
ment would by default be via Ethernet. Ethernet does not provide a QoS guaranteed and
very low-latency link (see discussion of dedicated buses elsewhere in this document), but
it has flexibility & bandwidth and is quick enough for many of the lower speed ADAS
functions such as parking.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 33
of 63 DESERVE Deliverable D25.2
This approach allows early access to real hardware capabilities and real optimized
versions of libraries such as Infineon’s discussed in his document. It can also support
decisions about future hardware, if ECUs as examples of possible targets exist.
2.5. FPGA-based platform to emulate hardware modules
The FPGA-based development platform can be used to emulate different hardware
modules that perform different signal processing operations. The modules can be imple-
mented independently and can be easily added to the generic bus-based platform. This
allows a modular construction of different complex driver assistance algorithms and
applications by interchanging the different hardware modules.
The modular concept increases the possibility for reusing existing modules in different
projects and can therefore lower the development time. It also allows characterizing the
single hardware modules by quantitative cost models, which can guide the development
process towards hardware and cost efficient implementations.
The architecture of the FPGA-based platform associated with a specific DESERVE
development system is outlined in Figure 14. The FPGA board includes a powerful Xilinx®
Kintex-7 FPGA allowing several signal processing blocks for perception algorithms to be
integrated. Moreover, the FPGA provides high speed connectivity by means of a Gigabit
Ethernet connection to PCs. Finally, the FPGA board supports up to 4 GB DDR3 RAM
memory so that even demanding applications, for example for processing video or radar
data, can be implemented.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 34
of 63 DESERVE Deliverable D25.2
Figure 14: FPGA-based platform with the DESERVE development system
A flexible and modular AXI bus infrastructure (AXI bus, [10]) is used as a template for
any FPGA hardware design. This template can be expanded with new signal processing
blocks by connecting these blocks to the bus.
The FPGA board also allows the integration of real hardware-accelerators. For example, a
radar front-end may directly be connected to the FPGA using a dedicated piggy-back
module and the actual radar logic is implemented in the FPGA. It is even possible to
directly interface a target microcontroller such as Infineon AURIX.
Further details are provided in the DESERVE deliverable D2.1.2 [14].
2.6. Testing process for the hardware architecture
The validation of the hardware architecture (including electronic operation) can be
defined as a set of specifications defining test methods for diverse components. This
process should guarantee that the hardware is as stable as possible, in order to reduce
possible failures in the performance of the system.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 35
of 63 DESERVE Deliverable D25.2
The reliability of ADAS systems is a necessity of the human safety. Therefore, testing
ADAS systems is a very important task which can prevent human errors and material
problems in the driving process, due to hardware or software failures. The testing of
ADAS systems allows evaluating the compliance of these systems with their specified
requirements.
The standard ISO 26262, for the functional safety of automotive electronics systems,
provides a good guidance on establishing safety requirements for their electronics
systems, performing hazard and risk assessments for embedded systems.
A recent report of the National Research Council (U.S.A) describes some the most
important challenges of electronics safety assurance in modern vehicles [1]:
Electronics are central to the basic functionality of modern automobiles.
o Growing of interconnectivity (devices and networks external to the
vehicle).
o Benefits on motorists (Safety).
To improve safety, fuel economy, emissions, and other vehicle performances.
o Depend on real-time coordination.
Hardware will require dependability assessments
o Further increases in software complexity.
o New sensors technologies.
Based on the procedure proposed in [1], the testing process for the hardware architec-
ture in DESERVE will be defined as follow:
Defining System Requirements: based on the platform requirements (D12.1)
and platform specification (D13.1) a list of hardware requirements (considering
each vehicle) will be provided.
Physical Inspection: this point covers:
o The quality of constructions –resistance and robustness-
o Physical design -practicality and size-
o Physical construction –no sharp edges and system fit-
o Accessibility -Toolless access and easily replaceable-
o Power -quality and easy-
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 36
of 63 DESERVE Deliverable D25.2
Testing via Software: It is the last process used to stress systems before
putting them in the vehicle. It is used to find faulty hardware. Hardware-In-the-
Loop (HIL) simulations for a variety of scenarios can be used. This technique
allows minimizing risks and testing the specified requirements in each scenario.
The manufacturer has the initial and primary responsibility for ensuring that these and
other electronics systems in the vehicle work as intended, do not interfere with the safe
performance of other systems, and can be used in a safe manner by the driver. The
hardware architecture is made up by sensors, calculators, CPUs and communication
buses that have to be tested individually then connected gradually.
External conditions have to also be considered in the hardware testing process. It is very
important to test the quality of sensor information. For example, testing visual interfaces
of ADAS in real situation and different visibility conditions: daylight and darkness, fog
and sunshine, cold or hot, among others…
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 37
of 63 DESERVE Deliverable D25.2
3. Software architecture
As for hardware architecture, task 2.5.2 identifies the characteristics and constraints that
the software architecture has to fulfill to accept an application based on modules deve-
loped inside the DESERVE platform (Figure 15). AUTOSAR standards will be considered,
but will not be treated as a pre-requirement.
Figure 15: DESERVE platform architecture
The key architecture challenges are:
AUTOSAR Standards Architecture for the full platform system including perfor-
mance accelerators
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 38
of 63 DESERVE Deliverable D25.2
Request for high SW re-usability / testability including re-use of older generation
software blocks
Fast time to market
High-optimized library for optimal performance
Automatic code generation
Standard Compiler/Tool chain
Finally, hardware tool software support for realtime debugging, high speed
parallel sensor data capture for validation and on-system debugging is required.
3.1. Specification of the software architecture
The hardware architecture, as defined and described in chapter 2.1, needs an accom-
panying software framework to work properly. A common, all-embracing tool chain that
spans over all the three development levels, would be ideal, but is not at all realizable
(even for the PC-based development level two “incompatible” operating systems, namely
Windows and Linux, exist).
In fact, the hardware architecture typically dictates the software structure and design on
large-scale.
What is needed is a software tool that operates in each of the three development levels
individually with the capability to conduct at least some general SW verification and
validation tasks. For the PC-based level1 development, there exist already open source
standardization initiatives like OpenCL or OpenCV that can be used in the respective
software tool chains. In Figure 16 functions of already existing software blocks in the
standardized toolbox for Computer Vision (CV) are shown. The availability of these same
blocks, with the same API, on diverse runtime hosts, allows the functional elements to
move between the hosts. Thus, the standard APIs and availability of these blocks as
resources is a key part of the software architecture.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 39
of 63 DESERVE Deliverable D25.2
Figure 16: Open CV functions
Another important aspect for the software design is the real time capability. Real time
operation system (RTOS) functionality is mandatory for the final target platforms of
development level 3. For the PC-based development level 1 the ability for RTOS is not
given for Windows™-related systems and only to a limited extent for embedded Linux
operation systems. For the intermediate level 2 (embedded controller development
phase) real-time operation can be guaranteed with the respective RTOS applied.
The next software requirement to be addressed is the bypassing functionality that
requires specific interfaces to bring the hardware accelerators in the loop. The hardware
in the loop (HIL) concept for the DESERVE development platform is thought to stretch
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 40
of 63 DESERVE Deliverable D25.2
over all the three development levels, i.e. the PC-based SW-tool shall be capable to do
HIL-bypassing with the embedded controllers of level 2 and the HW accelerators of level
3. A fundamental prerequisite to make this approach working is that the SW of all the
three levels respects the OSI model layer architecture that regulates communication by
specific protocols and instances.
Figure 17: OSI seven layer model for computer network communication
In Figure 17 the OSI model for computer networks is sketched for reference purposes.
The DESERVE platform may have less or slightly modified layers but should follow in
principle the general concept of the OSI model. The final SW architecture requirement
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 41
of 63 DESERVE Deliverable D25.2
can be also drawn out of Figure 17. The application layer with dedicated API functions is
essential for program abstraction and separation from the physical hardware peculiari-
ties.
In practice, most often an API is a library that includes specifications for routines, data
structures, object classes, and variables. An API specification can take many forms,
including an International Standard such as POSIX (a family of standards specified for
maintaining compatibility between operating systems), vendor documentation (such as
the Microsoft Windows API) or the libraries of a programming language (e.g., Standard
Template Library in C++, Java API, OpenCL or OpenCV).
With API programming techniques it is even possible to integrate hardware accelerators
into a high-level runtime environment of a computer. This corresponds then to PIL
(processor in the loop) acceleration techniques that may be needed to speed-up the PC-
based level 1 development stage of the DESERVE platform. The compliance with
AUTOSAR software architecture and principles should be maintained when designing the
respective DESERVE platform modules as far as needed. For automotive applications
AUTOSAR is anyway self-evident.
3.2. Application Software Modules
On the base of AUTOSAR standard, the general software architecture can be represented
in three main layers:
Low Level - Basic Software: this level abstracts from the HW, provides basic and
complex driver and services for high level (i.e. Memory, I/O).
Middle Level – Virtual Function Bus and Runtime Infrastructure
High Level – Application Software Components
The AUTOSAR standard introduces two architectural concepts (respects to other embed-
ded software architectures) that facilitate infrastructure independent software develop-
ment. Namely, these are the Virtual Function Bus (VFB) and the Runtime Infrastructure
(RTE) that are closely related to each other [9].
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 42
of 63 DESERVE Deliverable D25.2
In order to realize this degree of flexibility against the underlying infrastructure, the
AUTOSAR software architecture follows several abstraction principles. In general, any
piece of software within an AUTOSAR infrastructure can be seen as an independent
component while each AUTOSAR application is a set of inter-connected AUTOSAR com-
ponents. Further, the different layers of abstraction allow the application designer to
disregard several aspects of the physical system on which the application will later be
deployed on, like:
- Type of micro controller
- Type of ECU hardware
- Physical location of interconnected components
- Networking technology / buses
- Instantiation of components / Number of instances
Figure 18: Overview on the principles of virtual interaction using the AUTOSAR
The middle level, VFB, provides generic communication services that can be consumed
by any existing AUTOSAR software component. Although any of these services are
virtual. They will in a later development phase be mapped to actual implemented
methods, that are specific for the underlying hardware infrastructure. The RTE (runtime
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 43
of 63 DESERVE Deliverable D25.2
environment) provides an actual representation of the virtual concepts of the VFB for one
specific ECU.
An AUTOSAR software component in general is the core of any AUTOSAR application. It is
built as a hierarchical composition of atomic software components. The AUTOSAR soft-
ware component can be divided in Application Software Component and AUTOSAR Inter-
face.
All these concepts are strictly related to software implementation on embedded system.
Instead, DESERVE must cover all the development chain including ‘off-line’ simulation
and prototyping on high-level development platform. So it is important for DESERVE to
preserve (and build up during the prototyping phase of the applications) the AUTOSAR
modularity concept. Consequently, DESERVE focuses on the development of modular
Application Software Components.
The software architecture to be addressed by the DESERVE development framework has
been split into three platforms: Perception, Application and Information Warning Inter-
vention (IWI).
The baseline for DESERVE is represented by the results of past and on-going research
projects, and in particular of interactIVe addressing the development of a common per-
ception platform (Figure 19).
In this architecture the Perception Platform processes the data received from the sensors
that are available on the ego vehicle and sends them to the Application Platform in order
to develop control functions and to decide the actuation strategies. Finally, the output is
sent to the IWI Platform informing the driver in case of warning conditions and activating
the systems related to the longitudinal and/or lateral dynamics.
The architecture is suitable for the development and simulation of several groups of DAS
functions as identified in [6].For each Platform the complete list of software modules has
been defined in order to cover all the 33 DAS functions described in D1.1.1 deliverable
report [6]. The software specifications have been defined only for the modules to be
developed and integrated in the target applications (demo vehicle/motorcycle, test
bench, lab simulators).
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 44
of 63 DESERVE Deliverable D25.2
Figure 19: DESERVE Platform splitting
The software specifications of each module have been defined using a common template
and verifying the correspondence (number and data type of parameters) between the
input and output of possible linked modules. The report [8] is the first release of software
specifications to start modules development. During software development in WP3 and
WP4, a refinement of software modules parameter will be possible. The table in the
Annex A summarizes the defined modules.
3.3. Concepts for client-server access
As introduced in chapter 3 of the DESERVE deliverable D2.1.3 [15], the external bypass
method is an established and well recognized approach to developing and optimizing ECU
software functions. The original ECU performs all the software functions that do not need
to be changed, while new functions, or ones undergoing modification, are computed
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 45
of 63 DESERVE Deliverable D25.2
externally on a rapid prototyping system. The input and output variables of the bypass
functions are exchanged with the ECU via dedicated bypass interfaces. Computation of
each bypass function on the prototyping system is usually triggered by the ECU, so that
the two systems run synchronously.
More and more ECU functions require access to dedicated ECU services, e.g. to read or
write entries in the diagnostic error memory, the Non-Volatile Memory (NVRAM) or to
query the associated status. This kind of access is typically implemented in terms of a
client-server interface which defines a set of operations that can be invoked by means of
associated ECU service function calls. When it comes to developing higher level ECU
application functions on a prototyping system there is the general need to access the
above mentioned service functions on the ECU (see Figure 20)
Figure 20: External bypassing and client-server communication
As a rule, bypass implementations in the ECU require modifications to the ECU code.
Typically, a specific bypass service and calls to the associated service function, also
known as bypass hooks, are inserted into the existing ECU code for this. The main job of
these bypass service calls is to make the input variables X’ of each new bypass function
Y’=f’(X’) available to the prototyping system, to trigger the function calculation, and
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 46
of 63 DESERVE Deliverable D25.2
finally to feed the output variables Y’ of the function into the ECU’s code processing se-
quence. The bypass service contains an address table and data buffer in the ECU RAM
which allows a flexible definition of the ECU variables to be read and written by the
individual service calls without having to recompile the ECU code for this (see Service call
#1 and Service call #2 in Figure 21).
Figure 21: Service based bypassing extended by a concept for client-server
access
The concept for client-server access is based on the bypass service described above. This
service is extended by additional tables which contain lists of ECU functions (memory
addresses of the associated functions and call types) that can be invoked from the
prototyping system. The argument “call types” refers to different function call methods in
the binary code, for example methods compliant with EABI standard conventions for data
types, register usage, stack frame organization and function parameter passing [16]. In
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 47
of 63 DESERVE Deliverable D25.2
addition, the extended bypass service contains buffers for function arguments and func-
tion results.
A dedicated block in the Simulink model calculated on the prototyping system allows an
ECU function to be selected and to be associated with a bypass service call on the ECU.
The ECU functions available for client-server access on the ECU are defined in the
matching ECU variable description file [17]. This block feeds the function argument
values “u” into the respective fcn argument buffer, the service call on the ECU then
invokes the matching server function fserver() based on the related argument values from
the fcn argument buffer and sends the return values “a” back to the prototyping system
via the fcn result buffer and the bypass interface. For this, the bypass service function-
ality and the associated processing sequence are extended as given below:
1. New: Execute an ECU internal function call
2. Read data from the prototyping system
3. Trigger an interrupt on the prototyping system
4. Write data to the prototyping system
5. New: Execute an ECU internal function call
Depending on the configuration done in the Simulink model, no step, one, multiple or all
steps of this processing sequence can be executed by a call to the bypass service at
once.
3.4. Multi-task option to permit adding and removing of
functionalities
The modularity is one the most important directive in the design of a global architecture,
their functions and modules for embedded systems. Different multi-tasks (called pro-
cesses) can be executed by sharing common processing resources in the same CPU. In
this line, multi-thread languages as C++ are used by different developers around the
world.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 48
of 63 DESERVE Deliverable D25.2
The software environments used in the DESERVE platforms (e.g.: ADTF and RTMaps) are
able to transfer functions already programmed in C and C++. These tools are multi-sen-
sory software, designed for fast and robust implementation in multitask systems [4].
They use functional blocks (called components) for data flowing between different types
of modules: video, audio, byte streams, CAN frames, among others.
This multi-threaded architecture allows the use of multiple asynchronous sensors within
the same application (see RTMaps and ADTF sections in [4]). Moreover, they take advan-
tage of multi-processor architecture for more computing power.
Based on the Development Platform Requirements [18], there are three main stages in
the control architecture: perception, application and IWI platform. The goal of the
DESERVE approach is to add different functions (Multi-task) in the same platform.
3.5. Hardware optimized software functionalities
Advanced Driver Assistance Systems (ADAS) are systems to help the driver in the driving
task. When designed with a safe Human Machine Interface (HMI) they will increase
vehicle safety and more generally road safety. Examples for such systems are:
Adaptive cruise control (ACC)
Lane departure warning system
Lane change assistance
Collision avoidance system
Traffic sign recognition
Common to all those applications is that they are heavily using DSP algorithms primarily
for image and radar processing. As a general rule, most of the processor resources will
be consumed by the algorithmic part of the application. Availability of an AURIX (see
footnote 1 on page 29) DSP optimized algorithm contributes to high performance execu-
tion and significant reduction of application development time.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 49
of 63 DESERVE Deliverable D25.2
3.5.1. Motivation for the DSP library
To achieve performance in code execution at a reasonable price in terms of power con-
sumption and chip area, utilization of compiler optimized code is not enough. An alter-
native is hand optimizing the C code in assembly but this will cost a lot of effort in terms
of time and will make the code architecture centric. The best compromise is to propose a
DSP library with standard signal processing capabilities and a standardized (or well
defined) API for further enhancements and code portability.
3.5.2. Function naming convention
Function naming convention listed in the table below shall be applied: The function name
consists of prefix (e.g. Ifx for Infineon Technologies) providing information on the owner
of the function, the function itself (e.g. fft for Fast Fourier Transform) and the data
format (e.g. RealF32 for real numbers float single precision). Functions will be assigned
to function groups, e.g. mtx (matrix functions) or img (image processing functions).
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 50
of 63 DESERVE Deliverable D25.2
3.5.3. Calling convention
Most of the implemented functions have associated instance structure used for transfer-
ring of function parameters. Following example explains the required definitions and
initializations before the function can be used.
Used functions:
void Ifx_mtxSvdRealF32 (struct Ifx_mtxSvdRealF32State *); //defined in
dsplib.h
Associated Structure declaration, also defined in dsplib.h:
struct Ifx_mtxSvdRealF32State {
enum Ifx_mode mode;
float32 * a;
float32 * w;
float32 * v;
uint32 m;
uint32 n;
};
Each structure has mode parameters defining the optimization level of the function. Addi-
tional parameters are specific for each function. Before a function can be used, first
variable of type Ifx_mtxSvdRealF32State needs to be defined and the structure mem-
bers require to be initialized.
3.5.4. Target Function list
Following functions are targeted to be implemented in the DSP library and optimized
based on TriCore hardware.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 51
of 63 DESERVE Deliverable D25.2
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 52
of 63 DESERVE Deliverable D25.2
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 53
of 63 DESERVE Deliverable D25.2
3.6. Use of ADTF together with FPGA based development platform
The use of ADTF together with the FPGA-based development platform allows to perform
the same basic or complex signal processing operations purely in software (implemented
as ADTF-Filters), purely in hardware (implemented on the FPGA), or in a combined
software/hardware environment. This combination provides the required flexibility in the
development process to evaluate new ADAS algorithms. An exemplary development
process for an ADAS application example is described in the following paragraphs.
The application example performs traffic sign detection in video camera images following
an algorithm from [5]. The single processing steps are depicted in Figure 22.
Figure 22: Overview of an exemplary sign detection algorithm
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 54
of 63 DESERVE Deliverable D25.2
The development process for an application starts with the implementation of the single
steps of the algorithm as ADTF-Filters in C/C++. This allows functional verification of the
algorithm using a pure software implementation.
One goal in using the FPGA-based development platform is to perform a design space
exploration of the application by analyzing the impact of different algorithmic parameters
in order to find a resource efficient implementation. Computationally demanding blocks in
an algorithm slow down this task. One possible solution is to use a hardware accelerated
simulation by shifting the critical blocks of the algorithm to the FPGA-based hardware
platform. For example, the connected component labelling step of the algorithm takes a
huge part of the execution time. If the step is implemented on the FPGA-based platform,
the simulation time decreases significantly. This leads to quicker responses to algorithmic
parameter changes and therefore speeds up the design space exploration process.
The implementation of the Institute of Microelectronic Systems (IMS) of this algorithm
with a combination of ADTF and hardware emulated on an FPGA development board was
presented at the DESERVE Special Track (DESERVE workshop) at the SAMOS conference
[11]. It reduces the execution time of the application by a factor of about 65 in this
particular case.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 55
of 63 DESERVE Deliverable D25.2
4. Conclusion
The basic idea and intention of the DESERVE project is to standardize the interfaces
between the three different development levels as far as possible:
Level 1: PC-based development framework
Level 2: Embedded controller development framework
Level 3: Dedicated hardware (e.g. ASIC / accelerator) development framework
In this deliverable both hardware and software aspects for the DESERVE platform system
architecture were addressed and described in chapters 2 and 3.
Following conclusions can be drawn:
The overall DESERVE concept of a stepwise transfer of functionalities from PC
level 1 via the embedded controller level 2 down to dedicated hardware accele-
rator level 3 is feasible: For the intermediate level 2 real-time operation can be
guaranteed with the respective RTOS applied.
Further software requirement to be addressed is the bypassing functionality that
requires specific interfaces to bring the hardware accelerators in the loop.
The hardware in the loop (HIL) concept for the DESERVE development platform is
thought to stretch over all the three development levels, i.e. the PC-based SW-
tool shall be capable to do HIL-bypassing with the embedded controllers of level 2
and the HW accelerators of level 3.
In addition to the need for high speed, low latency bus system for connecting
sensors, different processing levels and actuators, a couple of important hard- and
software architecture related topics became obvious. To develop suitable solu-
tions, modelling techniques will be employed.
Concerning DESERVE level 3, in terms of hardware acceleration, the implementa-
tion of e.g. radar or vision pixel processing on Infineon’s AURIX automotive multi-
core processor platform shall be feasible.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 56
of 63 DESERVE Deliverable D25.2
REFERENCES
[1]. International Organization for Standardization (ISO), ISO 26262, Road vehicles --
Functional safety, 2011.
[2]. Transportation Research Board, special report 308: the safety Promise and
challenge of Automotive electronics, Insights from unintended acceleration,
National Research Council of the national academies.
[3]. Goebel, J. “Hardware Testing and System Qualification: Procedures to Evaluate
Commodity Hardware and Production Cluster” Stanford University Report, SLAC–
PUB–9761, 2004.
[4]. DESERVE Deliverable D13.2 - Method and Tools Specifications, SP1 Requirements
and Specifications.
[5]. Maldonado-Bascón et.al., Road-Sign Detection and Recognition Based on Support
Vector Machines, Intelligent Transportation Systems, 8, 2007
[6]. DESERVE Deliverable D1.1.1 - Application Database
[7]. DESERVE Deliverable D1.3.1 – Development Platform Specification, SP1
Requirements and Specifications.
[8]. 4_DESERVE_COLLECT_Reqs_Specs_v34.xls, SP1 Requirements and Specifications.
[9]. AUTOSAR GbR. Specification of the virtual functional bus, 2008.AUTOSAR
[10]. AXI Reference Guide, http://www.xilinx.com/support/documentation/
ip_documentation/ug761_axi_reference_guide.pdf
[11]. F. Giesemann, G. Paya-Vaya, H. Blume, M. Limmer, W. Ritter. A Comprehensive
ASIC/FPGA Prototyping Environment to Explore Embedded Processing Systems for
Advanced Driver Assistance Applications. International Conference on Embedded
Computer Systems: Architectures, Modeling and Simulation (SAMOS), 2014.
[12]. DESERVE Deliverable D2.1.4 - Development Method
[13]. PCI Express – PCIe: http://de.wikipedia.org/wiki/PCI_Express
[14]. DESERVE Deliverable D2.1.2 – Development System (Final Release)
[15]. DESERVE Deliverable D2.1.3 – Development Method (First Release)
[16]. EABI standard conventions: http://en.wikipedia.org/wiki/EABI#EABI
[17]. ASAP2 file: http://www.asam.net/
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 57
of 63 DESERVE Deliverable D25.2
[18]. DESERVE Deliverable D1.2.1 - Development Platform Requirements
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 58
of 63 DESERVE Deliverable D25.2
ANNEX A
PERCEPTION PLATFORM SW MODULES
Module name SW
name
Description
3D Reconstruction SD-R The 3D Reconstruction module estimates the spatial structure of the scene in
front of the car.
ADASIS Provider
ADAP
ADASIS Horizon module provides to applications information about current
position of the vehicle in respect to the digital map. In addition, digital map
information on current position and along predicted driving paths is given to the
application.
Perception Platform shall include an ADASIS Provider for provision of
predictive map data.
ADASIS
Reconstructor
ADAR ADASIS Horizon Module shall include an ADASIS Horizon Reconstructor to
reconstruct data from ADASIS Horizon Provider
Detection of the free
space
DFS The module detects the free/drivable on- and off-road space in front of the ego
vehicle in order to provide information about where the vehicle can go in a
short term.
Driver Monitoring
Automotive
DMA The DMA module shall monitor the driver status reported by the available
sensors. If this information is available from multiple sensors, this shall be
fused to give a more accurate, more reliable and unified report on the driver
status.
Driver Monitoring
Motorcycle
DMM The DMM module for motorcycle shall monitor rider/driver awareness status by
the one or more camera sensors. Module calculates gaze direction of the
rider/driver and activity (awareness) index of the rider/driver. DM motorcycle
module provides reliable and unified report on the rider/driver status to the
application platform.
Enhanced vehicle
positioning
EVP The module provides a more accurate absolute vehicle position compared to
standard GPS position using vehicle motion and lane detection data.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 59
of 63 DESERVE Deliverable D25.2
Environment ENV The module provides environmental parameters like temperature, rain
intensity, visibility, etc.
Frontal near range
perception
FNRP The module delivers the environmental description of the area in front of the
host vehicle, reporting all relevant obstacles that can be detected by the
sensor platform.
Frontal object
perception
FOP The objective of the module is to detect every relevant obstacle in the front
area of the ego vehicle including stationary and moving objects and provide
information about these objects
Lane Course LC The Lane Course module determines the trajectory of the lane in front of the
car up to a meaningful distance.
Lane recognition LR The module detects the lane border on the images of the front camera; this
information is then used to derive the geometry and position of the lane with
respect to the vehicle. The range for distance of interest may be between 30m
and 50m in front of the car.
Moving object
classification
MOC The module classifies different types of moving objects into several predefined
categories.
Occupant monitoring OM The OM module shall monitor the occupant status reported by the available
sensors.
Parking lot detector PLT This module detects and measures potential parking spaces. The information
is used for parking assist systems.
Recognition of
unavoidable crash
situations
RUCS The module is intended to recognize and predict (estimation of a crash
probability and severity) only unavoidable crash situations. The prediction time
frame is limited to a certain maximum threshold.
Relative positioning to
the road of the ego
vehicle
RPR The module estimates the position (longitudinal and lateral position of the
vehicle on the road segment) and motion of the host vehicle in relation to the
road.
Road data fusion RDF The module provides the following information, with better accuracy, for the
current road segment: number and width of lanes, lateral position of the vehicle
on the road, precise curvature profile.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 60
of 63 DESERVE Deliverable D25.2
Road edge detection RED The module determines the physical road boundary that does not necessarily
corresponds to lane markings. This information is needed to understand which
margin outside of the lane is available for the vehicle wheels before entering
an off-road condition.
Scene Labeling SL The Scene Labeling Module estimates class membership values for each
pixel.
Self Calibration SC The Self Calibration module estimates the calibration information required for
the 3D reconstruction.
Side/rear object
perception
SROP The module detects and delivers objects in the rear and side area of the ego
vehicle including also the blind spot.
Traffic sign detector TSD This module detects specified types of traffic signs relevant for the driver´s
task.
Vehicle light detector VLD This module detects the front and rear light of vehicles such as cars, trucks,
bikes, etc. This information is used among other for light control.
Vehicle state VS The module determines the current motion state, e.g. speed, yaw rate etc, of
the vehicle using all available information.
Vehicle trajectory
calculation
VTC This module deals with the forecast of the trajectory currently followed by the
driver in terms of future ego-vehicle positions and speed profile.
Vulnerable road
users
VRU The VRU module shall report the position and velocity of all vulnerable road
users reported by the available sensors. If information about VRUs are
available from multiple sensors this information shall be fused to give a more
accurate, more reliable and unified report on the VRUs.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 61
of 63 DESERVE Deliverable D25.2
APPLICATION PLATFORM SW MODULES
Module name SW
name
Description
ACC control ACC This module is a cruise control system with enhanced functionality that helps the
driver to keep a safe distance to other traffic ahead and alerts the driver if
manual intervention is required.
Activation control AC The module checks if the system should be activated.
Advance-Warning
generator
AWG The module detects, if there is a dangerous situation where evasive steering is
potentially needed.
Calculation of
required evasion
trajectory
RET This module calculates the predicted trajectory which is necessary to avoid a
collision with a detected obstacle, on foundation of the results of the sensor-
fusion part and assumed driver capabilities.
Decision Unit DU This module determines the best course of action. It controls the inputs for all
actuators and the HMI sub system.
Driver Intention
Detection
DID The module aims at identifying the driver intention to perform some maneuvers
in the current driving situation e.g. lane change, overtaking, car following.
Driving strategy DS This module aims at minimising the risk identified by the Threat Assessment.
Intervention path
Determination
IPD This module is responsible, once an intervention is required, for determining the
desired host vehicle trajectory necessary for the host vehicle to follow in order to
avoid the collision.
IWI manager IWI The Warning and Intervention module uses the output of the Application layer
and provides ways to execute the interaction with the driver and the control of
the vehicle
Reference
Manoeuvre
RM The reference manoeuvre is the recommended trajectory and speed of an
artificial-codriver which is as similar to a human driver as possible.
Situation Analysis SA the situation analysis gives an interpretation of the current surroundings, based
on the sensor data .
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 62
of 63 DESERVE Deliverable D25.2
Target Selection TS The module determines which is the most relevant target vehicle, starting from
the data received from the Perception Platform and the current predicted driving
situation for the addressed safety function.
Threat
Assessment
TA The module assesses and classifies the longitudinal and lateral risks associated
to the current situation. As a result it provides specific measures like TTC (time-
to-collision) and TLC (time-to-lane-crossing).
Trajectory control TC This module processes the calculated trajectory in order to derive the necessary
parameters and values for Vehicle Control.
Trajectory planning TP In case of an intervention or in automatic mode, this module calculates based
on the output of the Perception Horizon and the Threat Assessment/Driving
Strategy a safe trajectory in allowing the avoidance of a threat or a collision.
Vehicle model VM This module determines desired longitudinal acceleration requests and steering
wheel angle.
Vehicle Motion
Control
VMC This module determines in case of an intervention or in automatic mode the
desired longitudinal acceleration and steering wheel torques requests based on
the results of the components trajectory planning and control.
Platform System Architecture –
2nd Release
SP2 – WP2.5 - D25.2
Restricted Copyright DESERVE
Contract N. 295364
04.10.2014 Page 63
of 63 DESERVE Deliverable D25.2
IWI PLATFORM SW MODULES
Module name SW
name
Description
Acoustic AC Provides information and warnings to the driver (verbal messages and acoustic
signals) upon request from the applications.
Telltales TEL Provides information and warnings to the driver (different kinds of visual signals)
upon request from the applications.
Displays DIS Provides information and warnings to the driver (icons and text) upon request
from the applications. Displays like HuD, ...
External lights EL Communicates with road users outside of the egovehicle by controlling the
external lights
Warning Steering
Wheel
WSW Provides feedback to the driver in form of steering torque or
steering vibration
Warning Accelerator
Pedal
WAP Provides haptic feedback to the driver by the acceleration pedal (vibration,
knocking or pressure)
Warning Safety Belt WSB Provides feedback to the driver by tensioning the safety belt or generating a
vibration through a vibrating pad.
Steering Angle
Controller
SAC Calculates an overlay request torque that minimises the difference between the
actual wheel angle and the requested reference wheel angle from the
applications
Steering Torque
Controller
STC Makes sure the actual assist torque follows the requested overlay torque.
Brake deceleration
controller
BDC Executes a vehicle deceleration by acting on the braking system.
Engine acceleration
controller
EA Realizes the determined engine acceleration or deceleration.