platform system architecture 2nd release - deserve project...platform system architecture – 2nd...

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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014

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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


LIST OF TABLES

None


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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

http://en.wikipedia.org/wiki/Functional_Safety


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


SoC System on Chip

SPU Signal Processing Unit

SW Software

VFB Virtual Function Bus


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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:


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014




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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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).


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


Figure 5: DESERVE rapid prototyping architecture for WP4.1, WP4.2 and WP4.3

Figure 6: HW platform for in-vehicle test


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


Figure 7: DESERVE rapid prototyping architecture for ACC with autobrake

Figure 8: ACC with autobrake functional architecture


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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}


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


{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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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-


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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…


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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].


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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).


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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).


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014



2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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 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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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/

http://de.wikipedia.org/wiki/PCI_Express

http://en.wikipedia.org/wiki/EABI#EABI

http://www.asam.net/


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


[18]. DESERVE Deliverable D1.2.1 - Development Platform Requirements


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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 .


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.


2nd Release

SP2 – WP2.5 - D25.2


Contract N. 295364

04.10.2014


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.

platform system architecture 2nd release - deserve project...platform system architecture – 2nd...

Documents