deserve platform – 2nd release

DESERVE Platform – Final release

SP2 – WP2.5 - D25.8

PUBLIC Copyright DESERVE

Contract N. 295364

DESERVE Platform – 2nd release

Deliverable n. D25.8 – DESERVE Platform – Final release

Sub Project SP2 ADAS development platform

Workpackage WP2.5 Platform System Architecture

Tasks

Authors Frank Badstübner

Ralf Ködel

Infineon Technologies AG

File name D25 8_DESERVE_Platform_Final_Release_v1.0.docx

Status Final, v1.0

Distribution Public (PU)

Issue date 31/08/2014 Creation date 09/04/2015

Project start and

duration

1st of September, 2012 – 42 months


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015

of 139 DESERVE Deliverable D25.8

REVISION CHART AND HISTORY LOG

Ver DATE AUTHOR REASON

0.1 2015-01-09 Frank

Badstübner

Table of contents and document structure

created, content of first version included

0.2 2015-01-26 Paul van

Koningsbruggen

Second version

0.3 2015-01-26 Joshué Pérez Review of document and contributions in

section 8.4

0.4 2015-01-27 Matti Kutila Restructuring the deliverable

0.8 2015-03-05 Frank

Badstübner

Consideration of task leader, WP leader and

coordinator comments; integration of

additional information; formatting and

preparation for start of project internal review

process

1.0 2015-04-09 Frank

Badstübner

Reviewer feedback integrated, final editing and

final formatting, preparation for submission


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


TABLE OF CONTENTS

REVISION CHART AND HISTORY LOG ....................................................................... 2

TABLE OF CONTENTS ............................................................................................. 3

LIST OF FIGURES .................................................................................................. 6

LIST OF ABBREVIATIONS ....................................................................................... 8

EXECUTIVE SUMMARY ........................................................................................... 10

1. INTRODUCTION .............................................................................................. 12

1.1. Objective and scope of this document ..................................................................... 12

1.2. What is the DESERVE platform? ............................................................................. 13

1.3. From traditional approach to generic DESERVE platform ........................................... 15

2. A FLEXIBLE DEVELOPMENT FRAMEWORK TO SEAMLESSLY SUPPORT THE ADAS

DEVELOPMENT LEVELS .......................................................................................... 18

3. MODEL-BASED DESIGN ................................................................................... 23

3.1. Rapid prototyping approach................................................................................... 23

3.2. Development system ............................................................................................ 27

4. A TOOL CHAIN FOR VIRTUAL TESTING .............................................................. 30

4.1. Virtual testing based on DESERVE framework .......................................................... 31

4.1.1. Model-in-the-Loop (MIL) .............................................................................................. 33

4.1.2. Software-in-the-Loop (SIL) .......................................................................................... 33

4.1.3. Hardware-in-the-Loop (HIL) ......................................................................................... 33

4.2. Simulation tools and adaptations for DESERVE ........................................................ 34

4.2.1. Driving Simulators ...................................................................................................... 34

4.2.2. Environment and sensor simulation tools ....................................................................... 37

4.2.3. Perception and fusion development tools ....................................................................... 42

4.2.4. Vehicle dynamics simulation tools ................................................................................. 46

4.2.5. Control algorithms development tool ............................................................................. 50


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


4.3. Interaction between the DESERVE platform and the simulators .................................. 52

5. A MODULAR APPROACH FOR FUTURE ADAS FUNCTIONS ...................................... 52

6. A COMMON IN-VEHICLE PLATFORM FOR FUTURE ADAS FUNCTIONS ...................... 54

6.1. Application needs ................................................................................................. 55

6.1.1. Application database ................................................................................................... 55

6.1.2. Application needs ........................................................................................................ 56

6.1.3. Preconditions for the determination of the platform modules ............................................ 58

6.1.4. Functional platform needs (modules) ............................................................................. 61

6.2. DESERVE platform requirements ............................................................................ 63

6.2.1. DESERVE platform framework ...................................................................................... 65

6.2.2. Generic DESERVE platform requirements (relevant to all development levels) .................... 67

6.2.3. Rapid prototyping framework requirements (development level 2) .................................... 72

6.2.4. Additional requirements for embedded multicore platform with FPGA (development level 3) . 74

6.3. Key performance indicators (KPI) to validate requirements ....................................... 74

7. DESERVE PLATFORM SPECIFICATION AND ARCHITECTURE .................................. 83

7.1. DESERVE platform specification ............................................................................. 83

7.2. DESERVE platform architecture .............................................................................. 86

7.2.1. Hardware architecture ................................................................................................. 88

7.2.2. Software architecture .................................................................................................. 91

7.2.3. Hardware optimized software functionalities ................................................................... 97

7.3. DESERVE platform interface definition .................................................................... 98

7.3.1. Definition of DESERVE interface architecture .................................................................. 98

7.3.2. Existing ADAS interfaces ............................................................................................ 102

7.3.3. Definition of next generation interfaces ........................................................................ 105

8. SAFETY STANDARDS AND CERTIFICATION CONCEPTS ....................................... 111

8.1. Safety impact of DESERVE .................................................................................. 111

8.2. Functional safety of road vehicles (ISO 26262) ...................................................... 112


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


8.3. Guidelines related to ISO26262 ........................................................................... 113

8.4. Safety and AUTOSAR .......................................................................................... 115

8.5. Safety mechanisms for DESERVE platform ............................................................ 115

9. METHODOLOGY FOR APPLICATION DEVELOPMENT UTILIZING THE DESERVE

PLATFORM ......................................................................................................... 120

9.1. Development process ......................................................................................... 120

9.2. Development phases of DAS applications .............................................................. 121

9.3. Analytical modelling approach for system on chip concepts ..................................... 127

9.4. Guidelines for application development ................................................................. 130

9.4.1. Co-design methodology ............................................................................................. 130

9.4.2. Deployment of hardware dependent software functionalities ........................................... 131

9.4.3. Guidelines related to ISO26262 .................................................................................. 133

10. CONCLUSIONS ............................................................................................. 134

REFERENCES ..................................................................................................... 136


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


LIST OF FIGURES

Figure 1: The DESERVE platform - the enabler for next generation ADAS systems ..........................................12

Figure 2: Some aspects to be considered for the DESERVE platform definition ...............................................13

Figure 3: DESERVE platform concept to speed up ADAS development process by more than 15% compared to

state of the art .......................................................................................................................................15

Figure 4: Illustration of today’s structure of ADAS too often as separate silos ................................................16

Figure 5: DESERVE platform enabled design and development process ..........................................................18

Figure 6: ADAS development process..............................................................................................................19

Figure 7: Model-based design and rapid prototyping of application functions ................................................23

Figure 8: Established rapid prototyping tool-chain for ADAS development .....................................................25

Figure 9: External Bypass approach with rapid prototyping ............................................................................26

Figure 10: DESERVE platform concept for developing ADAS algorithms ..........................................................28

Figure 11: DESERVE platform concept for real-time in-vehicle use cases.........................................................28

Figure 12: Simulator and perception platform, loop closed ............................................................................32

Figure 13: CRF Virtual Reality Driving Simulator operated using the SCANeR software ...................................34

Figure 14: Modularisation of ADAS functions from streaming data perspective .............................................53

Figure 15: Modularisation of ADAS functions from abstraction ......................................................................53

Figure 16: General ADAS architecture (Source: EU research project HAVEit, www.haveit-eu.org) ..................58

Figure 17: DESERVE platform module concept ................................................................................................59

Figure 18: DESERVE requirements template ...................................................................................................65

Figure 19: DESERVE platform framework ........................................................................................................67

Figure 20: Perception platform functional architecture ..................................................................................69

Figure 21: Application platform functional architecture .................................................................................71

Figure 22: DESERVE IWI platform ....................................................................................................................72

Figure 23: Specification template ....................................................................................................................84

Figure 24: Pieces of ADASIS specifications of the DESERVE platform perception module ................................85


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 25: DESERVE platform (e.g. for development level 2 - rapid prototyping system based on mixed PC and

embedded controller framework)..........................................................................................................87

Figure 26: DESERVE approach – use of common platform for all ADAS modules .............................................89

Figure 27: DESERVE platform architecture ......................................................................................................91

Figure 28: Open CV functions ..........................................................................................................................93

Figure 29: OSI seven layer model for computer network communication .......................................................94

Figure 30: Overview on the principles of virtual interaction using the AUTOSAR ............................................96

Figure 31: Data flow for a peer-to-peer connection over a physical link ....................................................... 100

Figure 32: Message box principle for intra-unit communication ................................................................... 100

Figure 33: AUTOSAR Application software concept ...................................................................................... 101

Figure 34: Camera Interface (CIF) overview .................................................................................................. 106

Figure 35: Output termination in LVDS connections ..................................................................................... 109

Figure 36: Communication between ADTF on host pc and processing elements implemented on the FPGA-

based hardware platform .................................................................................................................... 110

Figure 37: Implemented Gigabit Ethernet Interface between ADTF and an FPGA development board ......... 111

Figure 38: Module interaction implies changes in system behavior .............................................................. 112

Figure 39: SEooC safety mechanisms ............................................................................................................ 116

Figure 40: Top level safety requirements ...................................................................................................... 117

Figure 41: Fault Tolerant Time Interval (FTTI) definition ............................................................................... 118

Figure 42: Generic elements of safe computation hardware platform .......................................................... 119

Figure 43: Development phases of DAS applications..................................................................................... 122

Figure 44: Typical process with model-based development .......................................................................... 125

Figure 45: Design space exploration framework in the design flow for heterogeneous hardware architectures

............................................................................................................................................................ 127

Figure 46: Software framework .................................................................................................................... 131

Figure 47: Software development tools ........................................................................................................ 132


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


LIST OF ABBREVIATIONS

ABBREVIATION DESCRIPTION

ADAS Advanced Driver Assistance System

ADASIS v2 ADASIS Forum is an organization of all major vehicle manufactures

and System Vendors with the objective to define to standardize data

model to represent map data ahead of the vehicle (ADAS Horizon,

Electronic Horizon) as well to define standardized interface to enable

applications to access this ADAS Horizon.

ADASIS v2 Specification covers the design and development of the

CAN and C API interface between Digital Maps and ADAS applications

(Electronic Horizon). After its release in 2010 the ADASIS v2 Specifi-

cation, backed by the ADASIS Forum, is now accepted as the de-facto

standard.

ADTF Automotive Data and Time-Triggered Framework

ASIL Automotive Safety Integrity Level

CAN Controller Area Network

E/E Electrics and Electronics

FPGA Field Programmable Gate Array

GigE Gigabit Ethernet

GNU Indent

The GNU indent program can be used to make code easier to read. It

can also convert from one style of writing C to another. indent under-

stands a substantial amount about the syntax of C, but it also

attempts to cope with incomplete and misformed syntax. See [41] for

details.

HMI Human Machine Interface

http://www.ertico.com/adasisforum/


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


HW Hardware

IMS Institute of Microelectronic Systems

ISO International Organization for Standardization

IWI Information Warning Intervention

NIR Near Infrared

LVDS Low Voltage Differential Signaling

PC Personal Computer

SW Software

TCP / IP Transmission Control Protocol / Internet Protocol

UDP User Datagram Protocol

USB Universal Serial Bus

WI Warning Information


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


EXECUTIVE SUMMARY

The document summarizes the DESERVE platform concept. The DESERVE platform is the

key enabler for speeding up the development of next generation ADAS systems. 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: Rapid prototyping platform including software superstructure (e.g.

embedded PC / embedded controller with realtime operating system and FPGA)

Level 3: Fully embedded, AUTOSAR compatible architecture (e.g. multicore

controller with FPGA) for the evaluation of algorithms in realtime and implemen-

tation of safety requirements according to ISO 26262 (e.g. pre-certification for

testing on public roads)

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.

The deliverable focuses on the overall DESERVE platform and presents the key findings

to the public. In order to achieve common understanding, the deliverable starts with the

definition of the DESERVE platform (chapter 1). Chapter 2 gives an introduction into the

DESERVE development framework It also introduces the need for seamless transfer of

algorithms between the different developments levels starting from feasibility study and

ending at the real product.

To suit the easy transfer between the different development levels, model based design

methodologies are employed (chapter 3). Virtual modeling and testing tool chains are

applied for the development of new ADAS functions and presented in chapter 4. The

focus in both chapters is on the selection and adaptation of existing tools for DESERVE.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Future ADAS systems will be built on a modular approach; the most important modules

are introduced in chapter 5. Perspectives on modularization are presented. Emphasis is

laid on the modularization following the DESERVE platform requirements.

Chapter 6 is dedicated to the common in-vehicle platform for future ADAS functions. The

focus is on the description of the DESERVE platform requirements, the application and

functional platform needs. Further, this section summarizes the DESERVE platform

requirements including generic requirements and particular requirements for different

development levels. Finally, this section presents key performance indicators (KPI) to

validate the requirements.

On that basis architecture and specification of the DESERVE platform were defined

(chapter 7). dSpace Micro Autobox and Infineon AURIX based control units represent two

examples of DESERVE platform instances: The rapid prototyping platform based on

dSpace Autobox and FPGA framework for use during development level 2, thus for most

of the vehicle demonstrators; and the fully embedded solution (based on Infineon’s

multicore controller AURIX offering dedicated safety features and FPGA) for the

development level 3 focusing on AUTOSAR compatibility of MCAL and driver stack as well

as on safety mechanisms to allow ASIL D certification. Safety standards and certification

concepts are very important for future ADAS. Chapter 8, therefore, explains the safety

mechanisms developed for the embedded solution (development level 3) and the

certification concepts.

Finally, chapter 9 explains the methodology for application development based on the

DESERVE platform. The development process and the development phases of DAS

applications are described as basis for the analytical modelling approach for system on

chip concepts. Finally, guidelines for application development are presented.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


1. Introduction

1.1. Objective and scope of this document

The objective of this deliverable is to describe the second and final release of DESERVE

platform. D25.8 is the fourth of a series of deliverables documenting the work performed

to define the final release of the platform system architecture:

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 – Final release

As outlined by Figure 1, the DESERVE platform is the key enabler for speeding up the

development of next generation ADAS systems.

Figure 1: The DESERVE platform - the enabler for next generation ADAS systems

• Inter Urban Light Assist

for passenger car Daimler

• Driver impairment warning

system for cars CRF, Volvo

• End-Of-Tail-congestion

warning for motorcycles Ramboll

• Blind-Spot-Detection

for motorcycles Ramboll

• Motorcycle occupant detection

and classification Systems Ramboll

• Adaptive cruise control

for heavy trucks Volvo

SP1 - Requirements

Requirements &

Specifications

SP5 – Integration/Demo cars

SP3/4 – Functions and models

SP6/7 – Validation and exploitation

enabler for SP5

verification and

cost/benefit


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The DESERVE platform represents an open platform to be used by anyone. Consequently,

this deliverable was declared public. Further, it covers the entire spectrum of aspects to

be considered for the use of this generic DESERVE platform.

Please kindly note that the extensive work on the DESERVE platform cannot be

completely described in one document. This report makes reference to a manifold of

other DESERVE deliverables. As most of these deliverables are not publicly available,

essential findings in these reports were included here to provide a complete view on the

DESERVE platform.

1.2. What is the DESERVE platform?

This very first question in DESERVE work package 2 is by no means easily to answer.

When starting with the platform definition, a really huge amount of different aspects

needed to be considered for the generic and open platform concept (Figure 2). The

DESERVE platform is a generic platform as it relies on model-based design and virtual

testing tools. Its openness is based on the compliance with AUTOSAR standards. All

AUTOSAR members have access to these standardized interfaces.

Figure 2: Some aspects to be considered for the DESERVE platform definition

What is the DESERVE platform ?


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The DESERVE platform is not related to any specific hardware or software. In contrast, it

is generic and represents a new methodology and concept to develop future ADAS

systems more efficient and more flexible with maximum reuse of modules and

components due to well-defined processes and standardizations on architecture

and encapsulated module levels.

The DESERVE platform concept is illustrated in Figure 3. To develop new ADAS

application, common modules such as lane detection, vulnerable road user detection or

vehicle detection will be reused.

Requirements engineering is applied for next generation ADAS systems. By means of

model-based design (e.g. Matlab/Simulink/ADTF/RTMaps) fast implementation in ADAS

rapid prototyping framework is achieved (development level 2). Rapid prototyping results

are evaluated by Hardware-in-the-Loop (HIL), Model-in-the-Loop (MIL) or Processor-in-

the-Loop (PIL) test bench. In parallel, by making use of model based design space

exploration, specifications and requirements for System-on-Chip (SoC) can be derived at

a very early development phase, which supports cost prediction on basis of silicon area,

throughput etc. Both, validation by virtual testing and cost prediction indicate important

improvement potentials that need to be implemented in the next cycle of the iterative

development process.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 3: DESERVE platform concept to speed up ADAS development process by

more than 15% compared to state of the art

1.3. From traditional approach to generic DESERVE platform

Situation before DESERVE

No model-based access to perception and fusion algorithms

No AUTOSAR compatibility

DESERVE Platform:

„The journey is the reward“

ADAS application portfolio(compliant with DESERVE module concept)

Common Modules:

Lane course,

VRU detector,

Vehicle detector, ….

Functions:

Emergency brake,

VRU protection,

InterUrban Assist, ….

ADAS rapid

prototyping

framework

Specifications and

requirements for

System on Chip(SoC)

next generation embedded ADAS systems

Model Based DSEMatlab/Simulink/ADTF/RTMaps

Validation

and Test

Cost prediction

(silicon area,

throughput, Pv,…

HIL, MIL, PIL test bench

MicroAutoBox, FPGA-Board,

Embedded PC, Aurix,…

Ite

rati

ve

pro

ce

ss

> 1

5%

sp

eed

up


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


No library with available algorithms (for composing and evaluating new

algorithms)

Testing the application on real vehicles in real traffic scenarios is the approach

followed, together with some recording feature to allow the capturing of the

critical situations, where the solution fails for example, in order to reproduce them

in some way later in laboratory;

ADAS as separate silos (Figure 4).

Figure 4: Illustration of today’s structure of ADAS too often as separate silos

Objectives of the DESERVE platform

Market needs that drive DESERVE

DESERVE is driven by market needs, which are:

Enable a further growth of embedded systems and more specifically advanced

driver assistance systems (ADAS)

Master the complexity (both in system architecture and processing power) of

ADAS

Reduction in costs of components and development time of ADAS


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Seamless integration of the growing amount of functions within ADAS and the

corresponding vehicle.

DESERVE’s answer to the market needs

To meet these markets needs DESERVE aims at a novel design and more efficient

development process that is enabled by a platform. A platform that:

Provides a flexible development framework, reaching from early PC-based pre-

developments down to close-to-production hardware implementations on final

target systems on chip, to seamlessly support the ADAS development levels;

Constructs a tool chain to allow for modelling and evaluation via virtual testing of

new sensors, algorithms, applications and actuators during the whole design and

development process;

Forms a common in-vehicle platform for future ADAS functions based on a

modular approach and an architecture and interface specifications that are

compatible with AUTOSAR (access and easy-to-use also for non-project-partners)

Enables the integration of:

- safety mechanisms for pre-certification (generic safety requirements e.g.

for testing on public roads) and full requirements for ASIL D according to

ISO26262 (to prepare certification of later target platform)

- security mechanisms for pre-certification of connected ADAS according to

ISO27001

Novel design and more efficient development process

The intended design and development process is based on the well-known V-model and

fully DESERVE platform supported during all phases in the process. This is illustrated in

Figure 5.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


model based design

software implementation

Embedded software / programmable hardware

implementation

Hardware-in-the-Loop testing

Software-in-the-Loop testing

Model-in-the-Loop testing

user acceptancebusiness requirements

Compilation and configuration

Driver assistance designFunction design and

developmentFunction Configuration Function testing & validation

is this the driver assistance we want?

does the function behave as it should?

does the function perform in real-time?

does the vehicle driver accept and use the assistance?

Development level 1: PC platform

Development level 2: Rapid prototyping platform

Development level 3: Fully embedded, AUTOSAR

compatible platform

Figure 5: DESERVE platform enabled design and development process

2. A flexible development framework to seamlessly

support the ADAS development levels

This section introduces into the development methods and guidelines associated with the

DESERVE platform and outlines the benefits in terms of development cost and time

savings from the OEM perspective. Basically, the platform concept is based on three

pillars which reflect the different development levels and the transition of ADAS

algorithms from the prototyping to production phase in the automotive industry (see

Figure 6).

The DESERVE platform is a generic platform that supports all development levels

illustrated in Figure 6 as seamless as possible - from feasibility study to product

development.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 6: ADAS development process

Development level 1: PC platform

In the research and pre-development phase users typically require highly flexible tools

with an intuitive user interface and the implementation of ADAS algorithms may not

satisfy hard real-time requirements. Here, PC-based tools such as ADTF and RTMaps for

data fusion often constitute the basis for ADAS development.

Such tools provide a high user comfort and allow developers to implement and verify

algorithms directly on a standard MS Windows or Linux PC. Different kinds of sensors /

actuators and vehicle bus interfaces are available so that the algorithms can directly be

tested in a real environment. However, real-time calculation is not guaranteed, especially

with complex perception, fusion and tracking algorithms. In addition, there is no direct

support of Matlab/Simulink, AUTOSAR and the model-based design approach for

application functions. Finally, PC platforms as described above are typically not tailored

for stand-alone, in-vehicle use cases.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


To avoid a time-consuming redesign of perception, fusion or tracking algorithms when

implementing them on the final ECU hardware (production ECU), engineers are looking

for ways to evaluate different target hardware architectures according to given cost

criteria already in early development stages. This request is met by the design space

exploration (DSE) methodology and the SoC modelling approach.

Development level 2: Rapid prototyping platform including software superstructure (e.g.

embedded PC / embedded controller with realtime operating system and FPGA)

In the second development stage engineers go one step closer to a real-time implemen-

tation. Complex and computationally intensive algorithms are shifted to a powerful FPGA

to improve the realtime capability. In parallel to this, the FPGA platform allows different

target hardware architectures to be evaluated in combination with the selected algo-

rithms. To ensure a rapid implementation of the above mentioned perception, fusion, and

tracking algorithms in the FPGA, basic building blocks in terms of a library are provided

by the DSE framework. By means of this block-based modeling approach the time and

effort for implementing the associated algorithms can significantly be reduced.

Using an embedded system platform in this stage featuring both an FPGA and an

embedded controller also allows ADAS application algorithms to be designed by means of

models so that the associated development time can further be reduced. Compared to

the purely PC based framework real-time performance is almost guaranteed, though the

user comfort with programming the FPGA may be restricted.

Development level 3: Fully embedded, AUTOSAR compatible architecture (e.g. multicore

controller with FPGA) for the evaluation of algorithms in realtime and implementation of

safety requirements according to ISO 26262 (e.g. pre-certification for testing on public

roads)

The goal of this stage is to go one step further to the final target hardware and to

provide a stand-alone, in-vehicle rapid prototyping platform which, for example, can

even be used during test drives. This stage reflects the users’ need to evaluate and

experience the driver assistance system directly in the vehicle itself.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The standard PC is replaced by an embedded PC that is qualified for in-vehicle use in

terms of shock, vibration and temperature, similar to the other parts of the system. This

platform also allows the integration of hardware accelerators so that even highly

computational intensive algorithms may be tested in the vehicle. It is also possible to

interface target microcontrollers of production ECUs and to run certain algorithms there.

The complete platform behaves like a prototype ECU which can be operated by test

drivers which are not specifically instructed. For example, the platform can be started

and shut down via the vehicle’s ignition key.

The development platforms of all stages can be used together with the model-based

design space exploration approach for system on chip and libraries of basic building

blocks for the FPGA. By means of this the gap is closed when transferring perception,

fusion and tracking algorithms from prototyping to production, similar to the model-

based design approach with application functions using Simulink. Being able to use

already tested and validated building blocks and software modules greatly facilitates and

expedites the development process.

To support the model-based development of algorithms at all processing layers (percep-

tion, decision making, warning and control strategies) and to execute these algorithms in

the vehicle, the DESERVE platform level 3 needs to be fully compatible to the AUTOSAR

standard (note: as of today, no certified AUTOSAR 4.0 real-time operating system

including memory protection is available; its development is not subject of DESERVE).

In addition, at this development level, safety mechanisms need to be developed:

According to ISO 26262 the DAS system needs to be classified concerning the

Automotive Safety Integrity Level (ASIL). Many DAS systems require the highest

classification ASIL D. Suitable measures are required to fulfil the related strong

requirements. As the certification process is very much related to the hardware, just pre-

certification (e.g. for testing of the new DAS on public roads) is possible at this

development level.

As a result, OEMs are able to define early and precise enough the distinct requirements

for the final ECU hard- and software (e.g. required interfaces - which I/O and bus


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


system; computational power; memory requirements), including the safety mechanisms

(e.g. memory protection, lockstep operation).

Development level 4: Target production platform (e.g. multicore controller ECU with

integrated custom ASIC/FPGA/hardware accelerator)

On basis of the production hardware, the final certification of the ADAS takes place.

Within the DESERVE project, the generic DESERVE platform concept was validated.

Starting with purely PC-based development, algorithms can be outsourced step by step

to an FPGA or embedded controller prototyping system. In addition to the hardware

concept, a design space exploration and an analytical modelling approach for system on

chip is proposed. This software framework allows different target hardware architectures

for the implementation of perception algorithms to be evaluated according to given cost

criteria in early development phases. The software framework is coupled to the FPGA of

the DESERVE platform. The associated workflow will be supported by a library of basic

building blocks for the FPGA by means of which perception algorithms can be composed

and implemented quickly.

To validate the platform concept, three different realization instances of the generic

DESERVE platform are considered in the project:

Development level 1: purely PC based solution

Development level 2: Mixed PC/embedded control based on dSpace Micro Autobox

with FPGA framework (this platform will be extensively used for the ADAS vehicle

demonstrators)

Development level 3: Fully embedded platform based on Infineon multicore

controller AURIX plus FPGA. This instance of the DESERVE platform provides

realtime operating system and basis software fully compatible to the AUTOSAR

standard. Thus it is open and easy to use for all AUTOSAR members. It will also

feature safety concepts required for ASIL D and consider new radar/camera

interfaces.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


3. Model-based Design

3.1. Rapid prototyping approach

Applying model-based design, ECU application functions are typically developed by

means of the rapid prototyping approach. This way new controller strategies can be

implemented early in the development process in short iteration cycles and verified

directly in the vehicle. Established tool-chains for rapid prototyping in the automotive

industry are provided, for example, by the companies dSPACE and ETAS. Figure 7

illustrates the model-based design and rapid prototyping workflow. Especially the dSPACE

AutoBox and MicroAutoBox platforms featuring a real-time operating system and a

scalable, embedded controller and I/O based hardware architecture are widely used in

research and development.

Figure 7: Model-based design and rapid prototyping of application functions


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Typically rapid prototyping systems serve as a platform for the implementation of

application and controller algorithms, respectively, by directly interfacing sensors,

actuators and the vehicle bus. Compared to final production ECUs these systems usually

provide more processing power and virtually unlimited RAM and flash resources, so even

complex algorithms can be calculated in real-time.

Due to the model-based design approach, application algorithms that have been

developed in terms of Simulink models during the rapid prototyping phase, can easily be

transferred to the final production ECU. This ECU typically features a single or multi-core

microcontroller for processing the application algorithms. For this transfer, target code

generators such as TargetLink® [15] or the Embedded Coder® [16] are used which

allow ECU production code or even microcontroller specific code to be generated directly

from Simulink. If developers adhere to certain modelling styleguides right from the

beginning, exactly the same models can be used in the complete development process

from prototyping to production code generation. The associated tools usually support

AUTOSAR [17] software components on the application level as well.

AUTOSAR is a standard for the ECU software architecture in the automotive area, and it

provides means to facilitate the exchange and update of ECU software and hardware.

This includes the standardization of ECU basic software such as system services and the

microcontroller abstraction layer as well as interfaces for application software compo-

nents. Thus, the AUTOSAR standard supports the scalability of software and its transfer

to different vehicle and platform variants, the software integration from multiple

suppliers, and the maintainability throughout the entire product life-cycle. However,

AUTOSAR does not address the architecture of perception, fusion and tracking

algorithms.

These algorithms are typically developed on MS Windows® or Linux PCs using dedicated

software frameworks such as EB Assist ADTF [18] or RTMaps [19] which are described in

D1.3.2 [4] at detail. These tools allow various sensors and vehicle buses to be interfaced

and different kinds of algorithms to be implemented in terms of C/C++/C# code that is

embedded in specific blocks, also called “filters”. However, using standard PCs with a

Windows or Linux operating system does not always guarantee real-time behavior. In


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


addition, modelling tools such as Simulink are not directly supported by these

frameworks.

An established tool-chain for prototyping ADAS functions is described in Figure 8. This

tool-chain already provides interfaces to ADAS related sensors and actuators as well as a

flexible hardware concept for the implementation of the perception and application

platform as well as the IWI-Controller. In this regard, it already reflects the idea of the

DESERVE platform framework described in D1.2.1 [2].

Figure 8: Established rapid prototyping tool-chain for ADAS development

Basically there are two approaches to rapid prototyping: fullpass and bypass. With

fullpass, the prototyping system calculates the complete algorithms associated with a

certain ECU or application. All sensors and actuators are connected to the prototyping

framework, and it has full control of the associated system. With bypass, in particular the

external bypass approach, the prototyping system is used in parallel to an existing ECU.

The synchronized connection between the two systems is implemented via dedicated

bypass or ECU interfaces. Typically, only specific software functions that are under de-

velopment are offloaded from the ECU to the prototyping system as outlined in Figure 9.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 9: External Bypass approach with rapid prototyping

In contrast to the model-based design approach for application functions which supports

a seamless software transition from the prototyping to production phase, a similar

methodology for the development and target implementation of perception, fusion and

tracking algorithms is not yet established and standardized in the automobile industry.

Due to the associated complexity and the high amount of sensor data to be processed,

the related algorithms for driver assistance systems are usually computationally very

intensive and the implementation on the final embedded hardware requires real-time

performance. Purely software-based solutions are often not appropriate. Thus, for the

implementation of these algorithms on the target platform in the vehicle different system

on chip (SoC) architectures have to be evaluated. For example, the SoC architecture may

be based on an FPGA, a multi-core processor, DSP, an ASIC or combinations of them.

Ideally, the final hardware architecture is identified early in the development process to

avoid an algorithm redesign during the transition from prototyping to production. The

rapid evaluation of different implementation options according to given cost criteria, also

called design space exploration, is required for this (see chapter 5 in D1.3.2 [4]).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


3.2. Development system

The DESERVE development system is based on the RTMaps or EB Assist ADTF software

framework which already cover different development phases. These tools serve as the

primary interface to ADAS related sensors and as a platform for implementing, simulating

and testing the associated algorithms. In addition to RTMaps and EB Assist ADTF, a

dedicated software framework is provided by means of which different target hardware

architectures can be evaluated according to given cost criteria based on a design space

exploration and a modelling approach for system on chip. To allow developers to

compare different target implementations early in the development process, the above

mentioned software framework is couple to a real-time platform featuring a powerful

FPGA and options to integrate specific system on chip (SoC) devices, for example,

hardware accelerators. Using the combination of FPGA and SoC it is possible to

implement the algorithms on different hardware architectures and to compare the

results. This workflow is supported by a library of basic building blocks for the FPGA by

means of which the target application can be composed and implemented quickly. Being

able to use already tested and validated building blocks or software modules in this

context greatly facilitates and expedites the development of perception, fusion and

tracking algorithms.

To provide a tool-chain that is independent of the individual use case, a generic interface

to the FPGA is necessary so that the same communication driver on the PC and FPGA

interface code can be reused, no matter what sensors are actually connected. In this

regard the PC based development framework also serves as a kind of converter trans-

lating specific sensor interfaces and protocols to a generic one.

By means of the DESERVE platform concept outlined in Figure 10, ADAS algorithms can

be evaluated on the PC and, in terms of associated building blocks, on different real-time

hardware architectures with minimum overhead. As a result of this analysis, early

enough in the overall development process OEMs are able to define specific requirements

for the target ECU hardware.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


When it comes to the validation of new ADAS algorithms in the vehicle, for example

during fleet tests, a robust and stand-alone real-time prototyping system is required.

This system typically has to boot-up as fast as production ECUs and to be remote

controlled via the vehicle’s ignition key or via dedicated messages on the vehicle bus. For

this purpose the PC based development framework in Figure 10 has to be eliminated and

the sensors to be directly connected to the embedded controller or FPGA platform.

Figure 10: DESERVE platform concept for developing ADAS algorithms

Figure 11: DESERVE platform concept for real-time in-vehicle use cases


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Depending on the sensors used, specific interface modules may be required. In addition,

the perception, fusion and tracking algorithms have to be calculated completely on the

real-time development system (Figure 11).

RTMaps and EB Assist ADTF form the primary interface to the individual sensors (see

subsection 4.1.3 for details). For the transition from Figure 10 to Figure 11 it is required

to connect the sensors directly to the embedded controller or FPGA board of the

DESERVE platform. Different options are available for this purpose.

Sensor Interfaces to the Embedded Controller: Application algorithms running on

the embedded controller are typically programmed by means of the model-based

design approach and Matlab/Simulink. There are different blocksets available to

directly integrate sensor data:

o Radar, lidar, and GPS sensors as well as laser scanners are typically

interfaced via the CAN, FlexRay or Ethernet bus for which tailor-made

blocksets are available.

o Electronic horizon data, that means data about the road ahead like slope

and curvature information, is based on a digital map and the vehicle’s GPS

position and driving direction. This data is typically provided via the CAN or

Ethernet bus using the ADASIS v2 protocol standard [20]. For the recon-

struction of the electronic horizon in Simulink a dedicated ADASIS v2 HR

blockset is provided [21].

o Cooperative communication modules such as ITS-G5 radio adapters for

V2X communication are not yet available in production vehicles; however

the advent is already on the horizon. To interface V2X communication

modules from the embedded controller and Simulink, associated blocksets

are currently under development at dSPACE.

o Camera sensors may be connected to the embedded controller by means

of sensor specific conversion boxes translating, for example, LVDS to

Ethernet. In typical use cases video streams are directly fed into the FPGA.

Interface options to the FPGA board: The FPGA board of the DESERVE develop-

ment system provides various interface options.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


o Using a piggy-back concept, application specific hardware modules can be

designed and integrated in the overall system. The actual connection to the

FPGA is done by means of 12 pairs of differential LVDS lines (2.5 V, ≥ 625

Mbit/s per pair) so that even high data streams from radar front ends or

cameras can be realized. In addition 200 single ended high-range lines

(3.3V) are available allowing complex logics to be added and interfaced

with the FPGA.

o By means of this approach users are able to connect different types of

environment sensors to the FPGA in which the associated perception

algorithms or specific hardware accelerator modules may be implemented.

In addition, the piggy-back concept allows target microcontrollers such as

the Infineon AURIX [22] to be integrated. This way, for example, hardware

accelerators may be prototyped on the FPGA in combination with the final

production hardware.

Basically the DESERVE platform concept allows different commercial tools to be inte-

grated. To be able to set up dedicated sample applications and demonstrators in the

DESERVE context, specific implementations are chosen. In addition to the PC based plat-

form (development level 1) two different instances of DESERVE platform are considered

in DESERVE: The rapid prototyping system based on dSpace Micro Autobox is used for

development level 2, while the Infineon AURIX based platform is ideally suited for

development level 3 due to its safety features.

4. A tool chain for virtual testing

One of the main difficulties for ADAS application is the complexity of the scenario: the

usage of sensors, actuators and controllers with all their intrinsic bias in the real world of

road traffic. Testing the application on real vehicles in real traffic scenarios is the

approach followed, together with some recording feature to allow the capturing of the

critical situations, where the solution fails for example, in order to reproduce them in

some way later in laboratory.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The DESERVE platform enables virtual testing of the newly to designed and developed

application in the laboratory, to a level where real testing will be needed only for final

confirmation, allowing complete debugging of the application. Two types of virtual tests

are distinguished: virtual testing with artificial scenarios and virtual testing with data

acquired in a real-world scenario.

Artificial scenario testing is useful to verify the behavior of the applications on the most

difficult or critical traffic scenarios, without missing or false intervention. This type of

testing will also be very interesting for applications where there is a vehicle control, since

it need be based not on a predefined data stream, but on an interaction with the

simulation tools (data acquisition, vehicle control, new vehicle position, new traffic

scenario, data acquisition, etc.).

Data acquired in real-world traffic situations are useful to verify that there are no specific

misbehaviors of the application when it uses data with all the natural bias coming from

the real-world.

Modelling and development tools are specified in the public DESERVE deliverable D1.3.2

(section 4) [4]. Further information is included in deliverable D2.1.4 describing the

analysis of these tools and methods and the selection and adaptation of tools for the

DESERVE platform [8]. Tools for DESERVE were clustered into four categories. Virtual

testing solutions employed in DESERVE are described in deliverable D2.6.1 [13]. As

several of these deliverables are not publicly available, essential parts are included here

in order to provide a complete view on the DESERVE tool chain for virtual testing and

model-based design.

4.1. Virtual testing based on DESERVE framework

Several software applications, used typically in the driving simulators, are able to

produce traffic scenario images starting from descriptions of road geometry, vehicles,

surrounding objects, etc. Considering the characteristics of the camera used (position

and field of view) these tools are already able to provide the image as seen by a camera.

Based on the 3D traffic scenario constructed with the scenario description (this is the first


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


step of the simulation) it is possible to reconstruct also the signal acquired by other type

of sensors, like lidar or radar.

Those signals (video, radar, lidar ...) are available in the DESERVE platform as sensor

components. As a consequence, DESERVE partners are able to build diagrams for the

simulation mode, and reuse them also for the real scenarios. Indeed, the simulation

diagram and the real scenario diagram are almost the same, only the acquisition part of

the diagram has to be changed, while all algorithms and display mechanism remains

unchanged. Figure 12 shows this interaction between simulators and the perception

platform control diagrams.

Figure 12: Simulator and perception platform, loop closed

The ability to close the loop and to use either data from simulation or data from records

of real environment is very powerful. This enables the different scenarios to be modified

dynamically during the execution. The data source can be modified directly according to

the results of the algorithms. Using a real data set does not allow modifying the data

sources, and many algorithms outputs can’t be properly tested.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The DESERVE platform considers MIL SIL and HIL [13]. Virtual testing will be mainly in

MIL/SIL to simulate sensors and to boost algorithms development without the need of

road testing at this point.

4.1.1. Model-in-the-Loop (MIL)

This is a case where you are using a model of the control to work with a model of the

car. The model of the control is probably in Simulink and is connected directly to a

physical model of the system within the same Simulink diagram (see section 4.2 for more

information on simulation tools). Extremely fast development occurs at this stage as you

can make small changes to the control model and immediately test the system.

In the DESERVE platform concept, model-in-the-loop is represented by RTMaps / ADTF +

Simulink + simulators, for example. The perception platform takes inputs from the virtual

sensor environment and runs calculations alone or with Simulink. Here we find most of

the prototype phase: algorithms can be developed and tuned quickly.

4.1.2. Software-in-the-Loop (SIL)

This is a case where the control model is slightly more "real" in the sense that you are no

longer executing the model but rather you have probably coded the model into C or C++

and then inserted this coded model back into your overall plan simulation. This is

essentially a test of your coding system (whether autocoded or human coded). Design

iteration slows down slightly from MIL but coding failures start to become evident.

In the DESERVE platform concept, software-in-the-loop testing is represented by RTMaps

/ ADTF and code generated by Simulink. As the perception platform uses C/C++ for its

component, there are no big differences between MIL and SIL.

4.1.3. Hardware-in-the-Loop (HIL)

This is a case where your control system is fully installed into the final control system

and can only interact with the plant through the proper IO of the controller. The plant is

running on a real-time computer with IO simulations to fool the controller into believing

that it is installed on the real plant. In this case, the only difference between the final


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


application and the HIL environment is the fidelity of the plant model and the test vectors

that you are using. HIL is often used only for software validation rather than develop-

ment as the design iteration is very slow at this point. However, this test is closest to the

final application and therefore exposes most of the problems that will be seen.

In the DESERVE platform concept, hardware-in-the-loop testing is represented by

RTMaps / ADTF working with dedicated instances of the DESERVE platform (e.g. dSPACE

microAutobox for development level 2 or Infineon AURIX for development level 3).

Indeed, the application running on the DESERVE platform instance would be generated

from Simulink, and dialog with the perception platform e.g. with Ethernet.

4.2. Simulation tools and adaptations for DESERVE

4.2.1. Driving Simulators

To get a more realistic feeling while driving and to perform user acceptance tests at as

early as possible in the ADAS development process, driving simulators are used. These

require a software suite, e.g. SCANeR. Figure 13 shows an illustration of the CRF Virtual

Reality Driving Simulator which is an example of system operated with the SCANeR

software.

Figure 13: CRF Virtual Reality Driving Simulator operated using the SCANeR

software


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


SCANeR (OKTAL)

SCANeR Studio is a software suite for human-in-the-loop driving simulations; it is

developed by OKTAL, and is based on works of the Vehicles Simulation and Perception

research group of Renault and works of SERA–CD.

Several European projects have been used as background for the development of the

software, examples are Prometheus, TRaCS (TRuck and Coach Simulator), CARDS

(Comprehensive Automobile R&D Simulator). The SCANeR software suite is capable to

cover all the main steps needed to develop a driving simulation experiment, to run it on a

wide range of driving simulation systems and to analyze the data coming from the

experiment; it is used by many research centers, universities and vehicle manufacturers

in the world.

Driving simulators can be very different in terms of hardware architectures and

capabilities, ranging from very simple systems with just a video game like steering wheel

controller and a small video display, up to very complex plants with large motion

systems, large screens, multiple force-feedback and surrounding audio. One of the

features of the SCANeR software is the ability to operate almost all the range of driving

simulators.

Software architecture: SCANeR is based on an open software architecture which

has the following main features:

o Communication back-bone based on Ethernet

o Distributed and modular structure

o Multi-platform (Windows, RT OS)

o Centralized application for supervision

The main modules of a SCANeR software system running an interactive driving

simulation session are:

o Simulation module: control the launch, execution and stop of all the other

modules, which together create the overall simulation.

o Acquisition module: acquires all the signals from cockpit commands and

manages the cockpit feedback activation.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


o Dynamics model module: computes the dynamic behavior of the

interactively driven vehicle.

o Visual module: generates the images projected on the screens, mainly the

external scenario, but can also visualize the interiors of the interactively

driven vehicle (this feature is used in some types of simulators based on

immersive virtual reality technology).

o Sound module: generates the sound of the interactively driven vehicle as

well as the sounds of traffic vehicles and other sounds of the external

scenario.

o Scenario module: execute scripts for the control of the simulation.

o Traffic module: generates the behavior of the autonomous vehicles which

constitute the traffic.

o Gateway for customer application: this module allows the integration of

modules which can be developed by SCANeR users, giving great flexibility

to the system.

Besides the above mentioned modules, SCANeR has other components as well, to

be used during the development and preparation of a driving simulation

experiment and during the final phase for data analysis.

Operating modes: The typical process for using SCANeR for driving simulation

experiments is composed by five main modes:

o Vehicle mode: within this mode the user can create the mathematical

model of the vehicle (car, truck or other types) and analyses the model

behavior.

o Terrain mode: here the user can create a road network including logical

information (as signs, traffic light, and speed limit) and including a 3D

graphical environment. However, for detailed 3D graphical model, a third

part tool is needed, such as for example the software CREATOR by

PRESAGIS.

o Scenario mode: the user can prepare a scenario, based on vehicles and

terrain, tune situations and manage autonomous vehicles of the traffic,


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


generate specific and dangerous situations, ask the driver to follow

instructions.

o Simulation mode: this is the mode for launching an interactive driving

simulation session, managing all the needed SCANeR modules, and

stopping the simulation at the end of the session.

o Analysis mode: after one or more simulation session, the user can analyze

the results using graphs, 3D animation, tables.

Interfacing with external specialized software: The open architecture of SCANeR

allows the integration of external specialized software; some example is:

o AIMSUN software by TSS (Microtraffic simulation)

o RTMaps by Intempora

o Eye tracking module (examples: Facelab, SmartEye)

4.2.2. Environment and sensor simulation tools

The development, testing and validation of multifunctional Advanced Driver Assistance

Systems (ADAS) are overwhelming tasks. It requires testing for a wide variety of driving

manoeuvres and critical situations that the system should recognise and handle.

Moreover, changes in environmental conditions will ever trim down the detection

performance.

For this reason environment / sensors modelling and simulation software platforms

(deliverable D1.3.2 [4]) offer engineers the opportunity to perform functional design up

to design validation of their driving assistance system from the early stages of the

development cycle. These tools allow to:

reproduce test scenarios for a wide range of environment and traffic conditions

emulate multiple perception sensors with realistic distortion effects

add system control with Matlab/Simulink interface

run tests with single or batch of scenarios

In the next paragraphs two tools, PreScan and ProSivic, fitting the former specifications

and the needs of the DESERVE platform are shortly described.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


PreScan (TASS)

PreScan by TASS International is a physics-based simulation platform that is used in the

automotive industry for development of Advanced Driver Assistance Systems (ADAS).

PreScan is also used for designing and evaluating vehicle-to-vehicle (V2V) and vehicle-

to-infrastructure (V2I) communication applications. PreScan can be used from model-

based controller design (MIL) to real-time tests with software-in-the-loop (SIL) and

hardware-in-the-loop (HIL) systems.

PreScan provides several capabilities to develop and test ADAS sensors and control

systems. Some of the most important characteristics are:

Sensor models: there are multiple kind of sensors that can be used to read the

environment information in PreScan, these are: Camera -mono and stereo-,

fisheye cameras, radars, lasers and lidars, ultrasonics, E-Horizon from ADAS, V2V

and V2I communication -DSRC antenna receivers (Rx), transmitters (Tx) and

standard message sets (e.g. SAE J2735 BSM)-, infrared -NIR-, among others.

Ground truth sensors: these functions are related to: SELF sensors - calibration of

tracking and tracing algorithms -, depth camera -calibration of stereo camera

algorithms -, lane marker sensor - calibration of lane warning or keeping systems

- and bounding box sensor -calibration of object and pedestrian detection algo-

rithms -.

Scenarios: different kind of scenarios can be used, for example:

o User-defined road network: straight road, curved road, roundabout and

crossings.

o 3D road segments and embankments: sloping roads, hill roads, bridges,

fly-overs and speed bumps.

o Road infrastructure: lane markers, pedestrian crossings, traffic signs,

traffic lights, light poles, matrix signs and guard rails.

o Road users: cars, trucks, animated cyclists and pedestrians.

o Environmental conditions: day & night conditions, different intensities of

rain, fog and snow, dirt spots and street lighting.

o Lighting effects: illumination, shadows, reflections.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Maneuver control: these can be tested in the simulator, but also can be linked to

Simulink (Matlab) to improve the performance. The most relevant are: open-loop

maneuvers with prescribed motion - Flexible path and speed definition -, closed-

loop maneuvers with PreScan vehicle dynamics - Open Simulink model of chassis,

transmission and engine and lateral and longitudinal controllers (driver models),

closed-loop maneuvers with 3rd party vehicle dynamics and - industry standard

vehicle dynamics codes (e.g. CarSim, DYNA4, dSPACE/ASM) and Driver-in-the-

Loop using steering console.

Interfacing: PreScan can be interfaced with different software and hardware:

Matlab & Simulink, RTMaps, ADTF, veDYNA vehicle dynamics, CarSim & TruckSim

vehicle dynamics, dSPACE ASM vehicle dynamics, AmeSIM vehicle dynamics,

dSPACE / Controldesk, National Instruments / LabVIEW and HIL tooling (ETAS,

dSPACE, National Instruments, OpalRT, Vector).

The program works using four steps:

Build Scenario: A dedicated pre-processor (GUI) allows users to build and modify

traffic scenarios within minutes using a database of road sections, infrastructure

components (trees, buildings, traffic signs), actors (cars, trucks, bikes and

pedestrians), weather conditions (such as rain, snow and fog) and light sources

(such as the sun, headlights and lampposts). Representations of real roads can be

quickly made by reading in information from OpenStreetMap, Google Earth,

Google 3D Warehouse and/or a GPS navigation device.

Model Sensors: Vehicle models can be equipped with different sensor types,

including radar, laser, camera, ultrasound, infrared, GPS and antennas for

vehicle-to-X (V2X) communication. Sensor design and benchmarking is facilitated

by easy exchange and modification of sensor type and sensor characteristics.

Add control system: A Matlab/Simulink interface enables users to design and

verify algorithms for data processing, sensor fusion, decision making and control

as well as the re-use of existing Simulink models such as vehicle dynamics models

from CarSim, Dyna4 or ASM.

Run experiment: A 3D visualisation viewer allows users to analyse the results of

the experiment. It provides multiple viewpoints, intuitive navigation controls, and


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


picture and movie generation capabilities. Also, interfaces with ControlDesk and

LabView can be used to automatically run an experiment batch of scenarios as

well as to run hardware-in-the-loop (HIL) simulations.

Finally, all the critical problems found in the design process can be solved in last stage.

ProSIVIC (CIVITEC)

Pro-SIVIC by CIVITEC is another powerful software environment for the assessment of

sensor robustness and reliability, and for the rapid and proven completion of perception

and detection systems validation. It comes easy to generate numerous variations of

environmental conditions while re-playing the same identical scenario to assess. This

simulator maximizes the performance and quality assurance of these systems in order to

be efficient and failsafe.

This simulator allows accurate simulations for perception and global control loop systems.

It brings the possibility of fully automated, semi-automated and driver assisted methods.

It considers different scenarios where all hypothetical conditions and circumstances can

be computerized and reproduced as in reality, including dangerous and hazardous

situations that are nearly impossible to play and replay in reality. Moreover, all the

dynamics conditions of each DESERVE platform can be added and simulated.

Some of the most important features of Pro-SIVIC are:

Platform for multisensory systems: it provides a software environment for the

assessment of sensor robustness and reliability, and for the rapid and proven

completion of perception and detection systems validation. It has the capacity to

simulate real-time physically realistic 3D virtual environment including, indoor or

outdoor infrastructures, occupants, traffic dynamics and multi-technology

perception sensors.

Sensors and Toolsets: Pro-SIVIC provides different sensors separated in three

main groups:

o Scalable Exteroceptive Sensors: Cameras and lidar rangefinders.

o Proprioceptive Sensors: INS, IMUs and Odometer


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


o References / Ground truth: Vehicle vector state, Pedestrian vector state,

Object vector state and Road state vs. vehicle state Reference sensors give

reference data regarding the exact state of various objects of the

simulation. This is convenient when validating sensor-based detection

algorithms.

Design and validation process: it identifies design and time to market, and

according to the stage in the design process, Model In the Loop (MIL), Software In

the Loop (SIL) or Hardware In the Loop (HIL) types of simulations are exploited to

assess systems specifications and performances.

These functions offer a wide range of possibilities for perception systems perfor-

mances assessment. The capacity of providing sensor reality like raw data makes

is key for the elaboration of cost efficient and proven MIL, SIL or HIL testing

facilities in Pro-SIVIC.

Vision Sensor: it allows identifying problematic cases during or after specification

and design stages of vision systems. Different realistic and flexible camera model

are available to simulate the behavior of real cameras, following system

specifications or a calibration process. Data fusion techniques can be implemented

to improve the robustness and reliability of data collected by different sensors.

Pro-SiVIC uses two types of geometrical 3D objects: simple polygonal models (or

meshes) used for small objects that one may want to interact with during the simulation

(buildings, trees, vehicles, pedestrians), and optimized polygonal models (using for large

static features, like terrains).

This simulator provides ambient lighting method in order to change the luminosity.

Punctual light sources (lamps and omni-directional) can be introduced in the simulator.

Moreover, projected shadows will allow testing the perception modules of the DESERVE

project: 3D Reconstruction, Frontal object perception, Self-Calibration and Vulnerable

road users (e.g. pedestrians, cyclists).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


4.2.3. Perception and fusion development tools

In the framework of model-based development methods for the efficient development of

embedded systems, perception and fusion development tools represent a main building

block. They support the vehicle application designer in easily creating new driver

assistance and active safety functionalities with a multitude of ready-to-use modules and

examples for optimized software components.

The following paragraphs introduce two important tools for DESERVE applications

development - ADTF and RTMaps.

ADTF - The Automotive Data and Time-Triggered Framework (Elektrobit)

This part of the report describes the Driver Assistance Application and Safety System

Development with the tool developed by Audi AEV and Elektrobit. The EB Assist Auto-

motive Data and Time-Triggered Framework (ADTF) support the software developer in

creating new functionalities with an extensive software development kit for driver

assistance solution.

ADTF is a flexible tool for the development of new functions in the car. The modular

system provides together with standard components a solid basis with open interfaces.

With the platform independent software development kit new functions can be efficiently

implemented. To protect the intellectual property the ADTF framework additionally offers

the possibility to exchange software components also in binary form.

EB Assist ADTF is able to capture asynchronous data from different sensor sources and

provides standard components for data recording and interpretation of LIN, MOST, CAN

and FlexRay bus systems. Besides data recording, the framework offers tools for real-

time data playback, data handling, processing and visualization in the lab as well as

online in the car. To support data exchange with proprietary tools, a so called “Streaming

Library” is available.

EB Assist ADTF simplifies the development process, especially the cooperation between

OEMs and suppliers. The initial development of the framework has been driven by a

major German OEM. Currently the product is in use by several renowned OEMs and Tier

1 suppliers.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The key performance indicators of ADTF can be summarized as follows:

Easy exchange of data and components

Flexible and extendable set of modules

Live visualization of data and results

Comfortable GUI for configuration and control

Real-time data recording, streaming and playback

Modular programming concept with straightforward interfaces (i.e. I/O pins with

cascadable filter programs)

The infrastructure of EB Assist ADTF provides the basis for the software development

cycle for driver assistance functions and supports the engineer in the software testing

and verification process. The framework connects a development environment with an

interactive work environment. Without writing a single line of code developers are able to

create new configurations by using the graphical user interface and existing modules.

The signal data flow between software components is defined by drag and drop and can

be executed immediately, so that the effects are instantly visible. The provided

examples, libraries and tool boxes facilitate the development of new and complex driver

assistance and active safety software modules which can easily be integrated into the

framework.

EB Assist ADTF describes a binary standard. Functional interfaces and data formats are

open for developers. ADTF is available for Microsoft Windows and Linux operating

systems.

GOLD (University of Parma)

GOLD is the main ADAS development framework used by University of Parma. GOLD is

able to provide the programmer with all the tools for a fast prototyping of applications in

the automotive field. It allows to acquire images from multiple cameras (analog, digital,

many different video formats) and data from many different sources (radar, laser

scanner, CAN data,…); all the acquired data are timestamped and stored on disk for an

efficient playback in laboratory. Accelerated graphical boards allow speeding up the

processing and the rendering of the results.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Applications are developed as plug-ins and may be detached from the GOLD framework,

once the algorithm is finally tested and freezed. While GOLD was born as a development

tool it can be also used as a real-time engine for the developed systems also enabling a

remote control or data inspect if needed. The GOLD software has been originally

developed for the Linux Operating System but is now also available for other operating

systems as well.

RTMaps (Intempora)

This paragraph focuses on RTMaps from Intempora SA, ultimate technology for real time

multisensor applications. Whereas most development software are not targeted at the

specific multi-sensor implementation obstacles, RTMaps technology has been originally

designed to focus on daily development constraints of such challenging applications and

their stakes. Its component-based development process releases the engineer or the

researcher from tedious tasks such as data acquisition, synchronization, recording,

playback, visualization and so on.

The main RTMaps software features can be summarized as follows:

Asynchronous data acquisition & processing

Supports any kind and number of sensors and actuators (including many camera

standards, CAN bus and DBC files parsing, GPS, IMUs, lidars, radars, etc.)

Precise timestamping

Graphical interface (RTMaps Studio)

« Block of components » functions building (hierarchical designs)

Modular and multithreaded architecture

Performance monitoring and customizable alarm generation

Component development in C/C++ with the RTMaps SDK

Master/slave mode with shared reference clock for distributed sensors and

actuators

Functionalities for advanced versatile data loggers design

Recording and real-time playback of sensors data

Interfaces with simulators


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Easy and royalty-free deployment of applications with the RTMaps Runtime

engine.

Customizable runtime graphical interfaces using higher level languages (QML, C#,

Java, XAML, Qt, C/C++…)

Widely used in industries, research labs and universities, RTMaps Technology acquires

data asynchronously i.e. “on the fly”, each data sample being captured at its own

genuine pace. Precise time stamps are assigned to each data sample. RTMaps modular

component-based architecture ensures easy application maintenance and upgradability

and allows productive re-use of previous developments. The exchange of software

components and recorded datasets also makes teams cooperate easily. RTMaps version 4

provides a lot of significant improvements such as a completely redesigned Studio (more

intuitive to be more efficient), a bunch of new components and diagnostics tools and

monitors, improved application deployment procedures, support of hierarchical

representation of components, better internationalization with UTF-8 support, and an

even more modular architecture.

The interfaces of RTMaps to ProSiVIC and SimuLink are described in detail in deliverable

D2.6.3 [23]. The interface between ProSivic and RTMaps is in responsibility of CIVITEC.

It internally uses ProSivic own Data Distribution Service (DDS) implementation, or shared

memory. The ProSiVIC package allows retrieving objects position, speed, direction, etc

directly in RTMaps.

RTMaps offers multiple ways to interact with Simulink: co-simulation where the two

environments run in parallel and code generation where the user can generate an

RTMaps component from a Simulink model.

Co-simulation:

UDP communication allows communicating between RTMaps, Simulink and

dSPACE prototyping systems over the network. This type of communication allows

software to be executed on different machines, which is very convenient in many

cases.

The Data Distribution Service for Real-Time Systems (DDS) is an Object

Management Group (OMG) machine to machine middleware standard that aims to


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


enable scalable, real-time, dependable, high performance and interoperable data

exchanges between publishers and subscribers. DDS is designed to address the

needs of applications like autonomous vehicle, financial trading, air traffic control,

smart grid management, and other big data applications.

Code generation:

Using Matlab / Simulink code generation capabilities, the user can generate an

RTMaps component with a Simulink model. The TLC (Target Language Compiler)

generates a Visual Studio project. Compiling this solution gives the RTMaps

component.

This approach allows running the application without Simulink. This can be easier

for deployment: one software program instead of two, and with RTMaps we have

the possibility to run on GNU/Linux as well. This can also be a faster solution

because it is compiled code, which is usually more efficient in term of speed.

4.2.4. Vehicle dynamics simulation tools

For driver assistance systems which interact with the steering, braking or throttle control,

a detailed model of the vehicle and its dynamic behaviour is essential. The simulation

tool used to predict the vehicle dynamics behaviour of the vehicle shall include a

mathematical model capable of calculating variables of interest for the test procedures

being simulated. For this purpose the vehicle dynamics simulation tool should be based

at least on a 14 degrees of freedom vehicle model, having the following subsystems:

Vehicle body

Wheels and tires

Primary suspensions

Steering system

Powertrain

Brake system (basic)

The “body” subsystem should include a six degrees of freedom rigid part representing the

vehicle overall sprung mass. Essential properties of it are the value of the mass, the

location of the centre of gravity and moments and products of inertia.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The “wheels and tires” subsystem should include two degrees of freedom rigid part for

each corner, representing the total unsprung mass related to the corner. A tire model is

necessary to describe vertical, lateral, and longitudinal contact forces and moments

between tire and road. Steady-state behaviour as well as transient dynamics shall be

included in the tire model.

The “primary suspensions” subsystem should include the characteristic curves that

determine how the wheel is located and oriented with respect to the vehicle body (under

the action of suspension jounce and contact forces and moments) as well as how forces

and moments from the tires are transferred to the sprung mass.

The steering system interacts with the suspensions to determine how the tire is oriented

on the ground: hence he “steering” subsystem should include kinematical and compliance

relationships needed to calculate the road wheel angles from the steering wheel angle.

The “powertrain” subsystem should include the description of how the engine torque is

transferred to the drive wheels through clutch, transmission and differentials.

The “brake” subsystem should include at least the functional model of the actuators

(brake torques as a function of corner pressures) and a generic function to define rear

pressures as a function of the front ones.

Other generic requirements of the simulation tool are:

the possibility to easily integrate external subsystem models (brakes, driveline,

ICT-based safety systems) developed in Matlab/Simulink

the possibility to easily supply vehicle model input data

the possibility to easily define driver inputs on primary controls (steering wheel,

gas and brake pedals, clutch, gear) in order to simulate generic vehicle dynamics

manoeuvres

the possibility to easily customize simulation output channels and to import the

simulation output files in Matlab

In the following paragraphs, two examples of vehicle dynamics simulation tools are

introduced.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ASM (dSPACE)

The Automotive Simulation Models (ASM) is a tool suite offering dedicated packages for

the simulation of driver assistance systems. ASM by dSPACE is described in some detail

in deliverable D2.1.3 “Development method (first release)” report [7].

The packages are open Simulink® models and are especially designed as plant models for

PC offline (MIL, SIL) and real-time simulation (HIL). For the latter use case the models

support real-time code generation via MathWorks’ Simulink® Coder™ and dSPACE’s Real

Time Interface.

The ASM Vehicle Dynamics Simulation Package is a comprehensive Simulink model for

the vehicle dynamics simulation in all phases of the model-based development process.

All the Simulink blocks in the model are visible, so it is easy to add or replace

components with custom models and to adapt the vehicle’s properties perfectly to

individual needs. ASM’s standardized interfaces allow the vehicle dynamics model to be

expanded to meet specific requirements or even create a virtual vehicle. Roads and

driving manoeuvres can be easily created using graphical tools with preview and clear

visualization.

The actual physical vehicle characteristics are represented by a multi-body system with

24 degrees of freedom. It consists of a drivetrain with elastic shafts, a table-based

engine, two semi-empirical tire models, a nonlinear or table-based vehicle multi-body

system with geometrical suspension kinematics and aerodynamics, and a steering model.

An environment with a road, manoeuvres, and an open- and closed-loop driver is

included as well. All parameters can be altered during run time. The included brake

hydraulics model consists of a dual-circuit hydraulics system.

The vehicle multi-body system is modelled as a nonlinear system with geometrical or

table-based suspension kinematics and table-based compliances. It supports the

simulation of vertical, longitudinal, and lateral dynamics. The kinematic behaviours of

common suspension types are implemented as precise analytical equations which are

solved during each simulation step. User-definable geometrical linkage points connect the

suspension with the wheel carrier and the chassis. There is no pre-processing required,


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


so the linkage points can be changed during PC offline and HIL simulation. In addition,

the vehicle model includes two tire models based on the published model descriptions

Magic Formula and TMEasy, which are both fully implemented.

The ASM vehicle dynamics models provide an excellent basis for developing and testing

vehicle dynamics ECUs, such as ESP, steering and active damping. They are ideal for

vehicle dynamics investigations in early development phases. Models for passenger

vehicles, trucks and trailers are available and they can be extended by other model

packages or custom models.

PELOPS (ika)

The traffic simulation tool PELOPS consists of three basic modules. The tool focuses on

the interactions of driver, vehicle and environment. Each module called driver model,

vehicle model and environmental model is designed independently but with well-defined

interfaces. Thus it is possible to choose different vehicles and driver types.

The influences of the traffic environment can be adequately represented by the

environment model. The course of the road is described not only by radii and transitions

in horizontal and vertical direction but also the number and width of lanes, etc. In

addition to this geometric information, the traffic signs and environmental parameters

can also be simulated.

This information is collected in an interface structure called “driving view” and is

submitted to the driver module which can react on these data. In the next calculation

time step the vehicle data (steering angle, acceleration, etc.) is taken to calculate the

updated environment status.

PELOPS also contains sensor models implementing the sensor characteristics (accuracy

and resolution of different signals, detection area, sample time, mounting position, etc.).

The vehicle model is able to receive information from the environmental model for the

current area around the related vehicle and the current vehicle status to calculate a

resulting force on the vehicle body. Also the yaw rate is calculated by PELOPS and can be

used by the environmental model to update the vehicle position in each calculation time

step. However the lateral and longitudinal dynamic of different vehicles can be simulated.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


In this module the vehicle dynamic characteristics are calculated based on the actuating

variables, such as pedal position, steering wheel angle and gear selection. In addition,

environmental data that influences the motion (gradient, inclination, etc.) are also taken

into account.

However, the focus of PELOPS is not on the vehicle dynamics and therefore uses only

simple dynamic models. In fact, the focus is on the interaction of the three mentioned

models (driver, vehicle, and environment) in order to realize a realistic traffic simulation.

4.2.5. Control algorithms development tool

The tool used for control algorithms development has to be so much faster than

traditional languages. The user can tune the implemented algorithm according to the

requirements of the project and simulate it in the context of a larger system model. The

tool allows exploring design alternatives to meet the requirements of limited memory and

hardware footprint. Once the algorithm is functionally correct, the user can optimize it in

terms of performance and maintainability. Integrated tools know how to identify potential

problems and recommend appropriate changes. Starting from the developed model, it is

possible to automatically generate C code and download it on the hardware platform. The

generated source code can be used for real-time and non real-time applications,

including simulation acceleration, rapid prototyping, and hardware-in-the-loop testing.

The user can tune and monitor the generated code or run and interact with the code

outside the development environment.

Furthermore this kind of tool allows non-intrusively finding operating points and compu-

ting exact linearization of the implemented models at various operating conditions. It

also provides tools for computing simulation-based frequency responses without

modifying your model. A graphical user interface (GUI) lets design and analyze arbitrary

control structures modelled by the user, such as cascaded, pre-filter, regulation, and

multi-loop architectures.

Summarizing, the tools for the design of control operations support every stage of the

development process, from modeling to the distribution system through automatic code


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


generation. The most important tool is Matlab/Simulink/Stateflow, which is briefly

described below.

Matlab/Simulink/Stateflow (MathWorks)

MATLAB is a high-level programming language and interactive environment for technical

computing, and includes functions for algorithm development, data analysis, numeric

computation, and visualization.

Stateflow® is an environment for modeling and simulating combinatorial and sequential

decision logic based on state machines and flow charts. Stateflow lets you combine

graphical and tabular representations, including state transition diagrams, flow charts,

state transition tables, and truth tables, to model how your system reacts to events,

time-based conditions, and external input signals.

Simulink® is a block diagram environment for multi-domain simulation and Model-Based

Design. It supports system-level design, simulation, automatic code generation, and

continuous test and verification of embedded systems.

Simulink provides a graphical editor, customizable block libraries, and solvers for

modelling and simulating dynamic systems. It is integrated with MATLAB®, enabling to

incorporate MATLAB algorithms into models and export simulation results to MATLAB for

further analysis. Simulink blocks can be developed in C/C++ (inside what they call “S-

Functions”), in Matlab or Fortran.

Simulink provides various blocks toolboxes for multiple domains. For control algorithms

development, the Control System Toolbox™ provides industry-standard algorithms and

apps for systematically analysing, designing, and tuning linear control systems. You can

specify your system as a transfer function, state-space, pole-zero-gain, or frequency-

response model. Apps and functions, such as step response plot and Bode plot, let you

visualize system behaviour in time domain and frequency domain. You can tune

compensator parameters using automatic PID controller tuning, Bode loop shaping, root

locus method, LQR/LQG design, and other interactive and automated techniques. You can

validate your design by verifying rise time, overshoot, settling time, gain and phase

margins, and other requirements.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Simulink is particularly powerful when it comes to code generation of control algorithms

towards execution targets. The Embedded Coder® generates readable, compact, and

fast C and C++ code for use on embedded processors, on-target rapid prototyping

boards, and microprocessors used in mass production. Embedded Coder enables

additional MATLAB Coder™ and Simulink Coder™ configuration options and advanced

optimizations for fine-grain control of the generated code’s functions, files, and data.

These optimizations improve code efficiency and facilitate integration with legacy code,

data types, and calibration parameters used in production. You can incorporate a third-

party development environment into the build process to produce an executable for

turnkey deployment on your embedded system.

4.3. Interaction between the DESERVE platform and the simulators

The communication between the simulator and the DESERVE platform is done via socket

(Ethernet). It is most of the time completely transparent for the final user. As a matter of

fact, most of the part of the application (RTMaps diagram) remains unchanged in both

cases: real data and simulation. Only the acquisition part has to be adapted, algorithms

and viewers are absolutely not aware from where data come from. This makes easy to

switch between real scenario and simulated scenario.

5. A modular approach for future ADAS functions

To enable re-use of both components (sensors, algorithms, applications and actuators)

DESERVE aims for a highly modular approach: The first perspective on modularization is

the streaming data perspective (Figure 14). Data streams from sensors in raw and/or

pre-processed form to software modules that build the perception of the vehicle state

and status and the theatre the vehicle is driving in (perception layer). Perception related

data streams to software modules that assess the vehicle state and status and the

theatre and generate and execute plans. Application related data streams to software

modules that transform decision into action in the form of warnings or advices to the

vehicle driver or interventions into the vehicle’s drive train control (see Figure 16, p. 58).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


physical level

Perception Application Advice-Warning-

Information

provisioning

(activation)

physical level

high levelmid

levelmid levellow

levellow level

Figure 14: Modularisation of ADAS functions from streaming data perspective

Physical Levelsensor signals and data

actuator configurations

plans

commands

control

theatre state, progress and exceptions

sensed and processed data, status updates

sensed signals and data

High Level plan generation

re-planning

objective capturing

reportingtheatre management

Mid Level plan execution exception recognition

fall-backsfall-backs

Low Level sensor data aggregation

sensor signal to data processing

sensed data analyses

control

Animate the physical world and collect its dynamic state

Sensors and actuators

Execute driver assistance

Capture and meet the dynamic driver assistance objectives

Figure 15: Modularisation of ADAS functions from abstraction


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The second perspective on modularization is the abstraction in reasoning by the software

modules. As depicted in Figure 14 already, four abstraction layers can be distinguished:

Physical level: processing sensor data and controlling actuators;

Low level: animate the physical world and collect its dynamic state;

Mid level: execute driver assistance;

High level: capture and meet the dynamic driver assistance objectives.

The abstraction in reasoning perspective is illustrated in Figure 15.

6. A common in-vehicle platform for future ADAS

functions

The DESERVE project intends to demonstrate an overall benefit and applicability of

results. The structure of technical work packages with the intention to demonstrate the

applicability of the generic and open DESERVE platform results by means of different

instances of realization in various demonstrators emphasizes this commitment.

A common requirements capture process was set, which spans over the entire DESERVE

project and underlays the willingness of the consortium to fully commit to this project

goal. With view on the development processes for safety-relevant designs (i.e. ISO

26262 in automotive domain or similar ones industries) a design flow is proposed. Such

flow requests to first of all generate high-level requirements and then to produce

“derived” (low-level) requirements relating to the high level ones. In the end a tracing is

performed that ensures that all requirements were covered. To that end, key perfor-

mance indicators (KPIs) were defined for validation of the project’s success, see

deliverable D6.1.2 [14].


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


6.1. Application needs

6.1.1. Application database

An application database was built first to get an overview of Driver-Assistant-Systems

(DAS) which are or will be offered in the automotive market in near future and to collect

the related application needs (high-level requirements). This set of DAS represents the

basic scope of functions to be covered by the generic DESERVE platform. It is described

in detail in the public deliverable D1.1.1 [24].

The advantages of such universal development platform for the development of next DAS

functions are manifold. Besides the advantage to rely and reuse many of the modules

already developed for earlier product generations the development time for new and

often more complex DAS applications can be even shortened or kept constant with much

higher added value and performance. This principle of reuse of already tested and

validated submodules is well known in general, but only in the early beginnings for

embedded systems.

The application database generated is the starting point towards the holistic DESERVE

development platform that is capable to meet the demanding requirements of future DAS

systems. It identifies 10 groups of DAS with 33 applications that are currently available

or will be introduced soon.

The database content is divided into 10 main DAS groups:

Lane change assistance system (Lane Departure Warning System, Blind Spot

Detection, Lane Change Assistance System, Overtaking Assistance System)

Pedestrian safety systems (Pedestrian Detection System)

Forward/Rearward looking system (Collision Warning System, Low Speed Collision

Avoidance System, Pre Safe System, Collision Avoidance System, Emergency

Braking ahead, Electronic Emergency Brake Light, Intelligent Intersection

(Emergency Vehicle Detection), Rear Approaching Vehicle, End-Of-Tail-Congestion

Warning)


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Adaptive light control (Adaptive High Beam Assist, Partial High Beam Assist, Inter

Urban Light Assist, Map supported Frontal Lighting)

Park assistant (Ultrasonic Park Assist System, Intelligent Park Assist, Rear View

Camera System, Surround View)

Night vision system (Night Vision System, Night Vision System with pedestrian

detection)

Cruise Control System (Adaptive Cruise Control, Adaptive Cruise Control -Stop &

go)

Traffic sign and traffic light recognition

Map supported systems (Curve Warning System, Fuel Economy System)

Vehicle interior observation (Driver impairment warning System (drowsiness,

fatigue, …), Driver/Rider visual Distraction Warning System (focus on the driving

task, eye gaze evaluation), Occupant Detection and Classification System)

Within these 10 main groups a subset of DAS applications, like e.g. adaptive high beam

assist in the DAS group Adaptive light control, forming the base modules for more

complex next generation DAS, are listed and described in more detail with respect to

sensor requirements, interfaces, actuators, HMI, interfaces and vehicle data.

6.1.2. Application needs

To identify the overall DESERVE platform needs in a first step the generalized and “ideal”

application needs, were derived.

Evaluation of the relation between the 33 DAS functions and required functional platform

modules led to the 10 application needs (see Table 1) to be satisfied.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Table 1: Application needs derived from the 33 considered DAS functions


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


6.1.3. Preconditions for the determination of the platform modules

The general ADAS platform concept and architecture is outlined in Figure 16 for applica-

tions starting from simple driving functions up to complex autonomous maneuvers.

Figure 16: General ADAS architecture (Source: EU research project HAVEit,

www.haveit-eu.org)

In a first level, the most prevailing functional modules of the platform were determined

and defined (see deliverable D1.1.2 [25]). With these, the functional block diagram on

module level can be generated (see Figure 17). Similar to the AUTOSAR concept each of

the modules has to be described with standardized I/O parameters and respective timing

requirements.

http://www.haveit-eu.org/


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 17: DESERVE platform module concept

It is worth to invest considerable effort in the complex design of the individual modules –

especially in the hardware design phase- but saving out of it far more manpower by

using more efficient hardware components (e.g. FPGA, ASIC) and –that is the key point-

by reusing it for next generation systems on a new hardware platform without doing the

extremely expensive coding, testing- and certification loop again.

In particular, the transfer of a function to the target hardware is one of the main cost

drivers during the development cycle for next generation driver assistant systems. New

driving assist functions have to be tested on dedicated prototype hardware, due to the

underlying real-time-conditions of a (pre)developing and testing phase. Afterwards the

algorithms have to be transferred to the series product specific target hardware, entailing

a redesign and recoding to the new hardware structure. Again very expensive test and

verification cycles have to be performed with these implementation levels (typically A, B

and C samples) before start of production (due to the different ASIL levels of the

functions) occurs.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


One of the main objectives of the DESERVE project is to avoid these very expensive and

unnecessary intermediate development levels during the product development process.

The idea is to use basic platform modules both during the (pre)development phases as

well as in the later serial product cycles. This leads to a significantly faster and more

cost-efficient development of new DAS functions.

To get reusable and hardware independent software modules some meta information

about the HW characteristics of the software modules must be added to the module

description already in a very early stage and a high abstraction level.

Based on this meta information a so called design space exploration methodology is

required at the beginning of the design process for the next generation ADAS system.

During the design space exploration phase it is possible to evaluate different partitioning

/ mapping alternatives concerning important characteristic features like resulting power

dissipation, silicon area, CPU usage of processor cores, number of required logic

elements on an FPGA, throughput rate, etc. to get the optimized hardware configuration

or the best sub-function distribution on a given hardware configuration for an ADAS-

function, composed of several functional platform blocks.

Only the system designer will be able to partition and especially map the system in such

a way that the required flexibility is provided. But in order to avoid time consuming

iterations over the different design level steps deeper hardware/architecture knowledge

is required even at a very high system level in the early concept phase.

A cost evaluation should support the system designer by allowing an exploration of the

prevailing design space. This evaluation requires information about the system

specification (e.g. filter parameters etc.) and meta data on the specific components in a

model library. Furthermore, a system partitioning and a mapping to specific architecture

blocks can be passed over to this evaluation. The key to this approach is the access to an

appropriate feature model library. This library includes parameterized models of the

characteristic features (silicon area, power consumption, throughput rate, …) for all the

functional blocks or kernels of an application domain (e.g. models for digital filter

architectures, disparity estimation, classification). For a powerful methodology supporting

design space pruning, a model library, which is as complete as possible, is required.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The cost evaluation supports the design by deriving feature estimates for the SoC to be

designed. Although those estimates will yield deviations from actual physical implemen-

tation figures, these estimates support the fast pruning of the design space without the

need for time consuming simulation runs. Non-feasible partitioning/mappings can be

avoided in an early design phase and therefore valuable design time can be saved.

Most decisive for such a concept is to elaborate suitable models for a variety of

frequently used basic operations and architectural blocks. It is one of the goals of this

project to build up such a library with powerful cost models for ADAS domain specific

modules and kernels.

6.1.4. Functional platform needs (modules)

In a first step the DESERVE platform modules have to be derived from the identified

application needs in such a way, that well sized modules with a high applicability and an

economically justifiable implementation effort were identified: The basic ADAS modules

and the necessary DESERVE platform components were identified, leading already to a

first hint with respect to the highest frequency of occurrence of the respective com-

ponents and platform modules. This analysis was kept on a rather high hierarchical level

whereby the DESERVE platform building blocks are expressed in intrinsic operational

modules (e.g. ego position on the road, relative movements of other traffic participants,

road boundaries, lane course, traffic sign recognition, pedestrian detector, driver status,

vehicle onboard status, environmental perception and risk management). The basic

DESERVE platform will be constructed from the functional modules having a high degree

of occurrence as identified in the cross-correlation matrix evaluation process. Platform

modules with less frequent occurrence will be only part of the extended DESERVE

development platform.

In a second step the DESERVE platform modules are examined to determine to what

extent they may provide input data or information to other components. The results of

the „Platform needs synthesis“ are shown in Table 2. Surprisingly only six basic modules

(color-marked lines) are necessary to realize sixteen DAS-functions. It is evident that for


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


these six basic modules a hardwired solution (e.g. an implementation in FPGA) is worth-

while on the long term.

Table 2: Ranking of highest level platform modules according to their number of

occurrences in 33 investigated DAS functions

The definition of the high level platform modules in Table 2 is based on DAS with a focus

to well-structured roads such as highways or interstate roads. Nevertheless these

modules also cover future applications with focus to smaller inter-urban roads. The

modules (on a generic level) remain the same but the requirements of the modules

increase. For instance, after the transition from pure highway roads to inter-urban roads,


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


the lane course module has to cope with higher road curvatures and sometimes missing

lane markings.

To summarize the procedure for the derivation of DESERVE platform needs, Table 3

exemplarily presents the relations between DAS system, application needs and platform

needs (which correspond to the required platform modules).

Table 3: Relation DAS system -> Application Needs -> Platform needs

6.2. DESERVE platform requirements

The next step in the definition process for the DESERVE platform concerned the

translation of the previously defined platform needs into generic requirements for the

DESERVE platform based on common software architecture and suitable for the

development and simulation of the 33 DAS functions investigated in the beginning.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The generic requirements for the DESERVE platform were defined utilizing the following

approach (see deliverables D1.2.1 [2]):

The DESERVE development platform has been defined taking into account that

general requirements such as AUTOSAR compatibility [17], SPICE compliance and

functional safety (ISO 26262) [29] - [33] are mandatory for industrial use. These

requirements apply for the “industrialized platform”.

The generic DESERVE platform addresses a functional software architecture based

on Perception, Application and IWI platforms and this architecture has been

analyzed in order to cover the 33 DAS functions defined above.

The list of software modules has been defined in order to be able to develop all

the 33 DAS functions but the functional requirements have been described only

for the specific modules that will be developed in DESERVE project for the safety

applications to be demonstrated (demo vehicle/motorcycle, bench test, lab simu-

lators).

The generic platform requirements have been formally described using the requirements

template depicted in Figure 18.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 18: DESERVE requirements template

6.2.1. DESERVE platform framework

DESERVE aims at designing and building an ARTEMIS Tool Platform with the objective to

reach a standardization of the interfaces, software reuse, development of common non-


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


competitive software modules, and easy and safety-compliant integration of standardised

HW or SW from different suppliers.

The DESERVE platform has been defined taking into account general requirements such

as AUTOSAR compatibility, SPICE compliance and functional safety (ISO 26262), which

are mandatory for the later industrial use.

The AUTOSAR standard comprises a set of specifications describing software architecture

components and defining their interfaces. DESERVE aims at using AUTOSAR to integrate

applications from different suppliers inside a single processing unit.

DESERVE addressed also to be compliant with the SPICE standard, which represents a

set of technical standards documents for the computer software development process

and related business management functions.

The ISO 26262 standard was considered in the implementation of DESERVE platform in

order to improve the safety in the development of methods and tools. The ISO 26262

standard defines the “Functional Safety Assessment” at the completion of the item

development with the scope to assess the functional safety that is achieved by the

element under safety analysis.

The baseline for DESERVE is represented by the results of past and on-going research

projects [34], [35], and in particular of interactIVe addressing the development of a

common perception framework for multiple safety applications with unified output

interface from the perception layer to the application layer [36].

Figure 19 presents the DESERVE platform framework. In this generic 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.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 19: DESERVE platform framework

6.2.2. Generic DESERVE platform requirements (relevant to all

development levels)

Different clusters of requirements were defined following the structure of the DESERVE

platform framework. Please note that each of the following requirements was divided in

sub-requirements, which are described in detail in DESERVE deliverable D1.2.1.

General software requirements

General software requirements: Among others, these cover the previously mentioned

software requirements for modularity, reusability, AUTOSAR, SPICE process assessment

(ISO/IEC 15504), functional safety (ISO 26262), platform independence (the application

software needs to be independent from the processing hardware), standardized

interfaces (i.e. the software needs to have interfaces to sensors and actuators that are

standardized and published), operating system independence (cross platform libraries are

recommended), programming language, communication technologies independence,


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


automatic start-up/shut-down, configuration of sensors position, software versioning and

licenses.

General hardware platform requirements

These cover the aspects power supply, list of supported sensors, processing unit, unit

size and number of included components etc.

Perception module requirements

These requirements include 3D reconstruction of the scene in front of the vehicle,

ADASIS horizon, assignment of objects to lanes, detection of the free space, driver

monitoring, enhanced vehicle positioning, environment, front near range perception,

frontal object perception, lane course, lane recognition, moving object classification,

occupant monitoring, parking lot detector, recognition of unavoidable crash situations,

relative positioning of the ego vehicle to the road, road data fusion, road edge detection,

scene labelling, self-calibration, side/rear object perception, traffic sign detector, vehicle

filter/state, vehicle light detector, vehicle trajectory calculation, vulnerable road users

detection and classification.

The functional architecture of the perception layer is illustrated in Figure 20. Depending

on the ADAS system to be realized, some of the components in the generic perception

platform architecture may be omitted (without losing generality). The modules developed

in the project to build the demonstrators are highlighted by thicker boxes.

The number and variety of the different perception sources is manifold and requires

special care and precaution to transport the available information in the subsequent data

processing modules. Two main aspects have to be taken into consideration when

connecting perception sources to the DESERVE platform:

The information content may differ from sensor to sensor even when the same

technique (e.g. radar, video camera or ultrasonic sensor) is used.

Based on the physical concept used the individual sensors may have an intrinsic

lack of information that can never be provided, independent of the effort spent to

improve the sensor performance (e.g. radar sensors can never “visually” read the


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


road signs content while video sensors can never provide direct speed

measurements).

Figure 20: Perception platform functional architecture

By using the general interface descriptor approach the data input structure for the per-

ception layer processing module becomes independent from the real sensors connected

to the DESERVE platform. This kind of concept is used in PC architecture since several


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


years under the term hardware abstraction layer that completely decouples data

information from the physical hardware in use.

The flexibility and scalability of the overall system is much better and reusability of SW

components that are already developed is higher. Improvements and changes within the

subgroups (i.e. environmental sensors or perception input processing module) can be

conducted on a standalone basis without modifying or adapting the whole data

processing chain at all. General adoption of the whole data processing chain is thus only

needed in the case that the interference descriptors between the modules have to be

updated or modified due to recently emerging needs.

As the diversity of the already existing environmental sensors is already huge and many

products are already in series production, the change of the sensor output signals is

often not possible at all. To connect already existing sensing devices or sensors with an

IP-protected signal output to the open DESERVE platform, a work-around with converter

or breakout boxes can be applied. Using such interface converter/breakout boxes almost

any kind of sensor system can be attached to the standardized and abstracted input

channels of the generic DESERVE platform.

Application module requirements

The application module needs to consider the following requirements: ACC control,

activation control, advance warning generator, calculation of required evasion trajectory,

decision unit, driver intention detection, driving strategy, intervention path

determination, IWI manager, reference maneuver, situation analysis, target selection,

threat assessment, trajectory control, trajectory planning, vehicle model and vehicle

motion control.

The functional scheme of the application platform modules is depicted in Figure 21. The

modules are divided in clusters having the same scope. Some of them have mainly the

objective to select the driver intention and the most dangerous target. Other modules

execute control operations and make an evaluation about the current situation of warning

and eventually decide specific actions. Then the type of information to provide to the


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


driver and the intervention strategy are decided. Finally, the kind of actuation to adopt is

provided to the IWI Platform modules.

Figure 21: Application platform functional architecture

IWI module requirements

The IWI module is dedicated to suit requirements regarding the HMI (acoustic, displays,

telltales, haptic steering wheel, haptic accelerator pedal, haptic safety belt), actuation of

external lights, lateral actuation (steering angle and steering torque controller) and

longitudinal actuation (engine acceleration controller).

The functional architecture of the IWI platform is depicted in Figure 22 below.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 22: DESERVE IWI platform

This section described the generic requirements for the DESERVE platform. As explained

in section 2, the different levels in the development process of ADAS require different

instances (i.e. realizations) of the generic DESERVE platform – from PC based

(development level 1) to production hardware (development level 4). With increasing

development levels, additional requirements need to be addressed. This principle shall be

explained in the next two subsections.

6.2.3. Rapid prototyping framework requirements (development level 2)

This section outlines the main requirements for the DESERVE rapid prototyping platform.

The main intention here is to specify a flexible and modular rapid prototyping environ-

ment allowing ADAS related perception, application and intervention algorithms to be

developed in short iteration cycles and to be prototyped directly in the vehicle. In order

to do so, there is a need to connect different kinds of sensors to the development frame-

work, to pre-process and fuse the sensor data, to calculate the actual ADAS applications

and to finally drive the respective actuators.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


In the following high-level requirements are listed. Following the structure for the generic

requirements in the previous section, the rapid prototyping system requirements are

structured in hardware, software and FPGA code requirements. In addition, a distinction

is made between perception (i.e. sensor data processing) and application algorithms.

Hardware platform requirements

This cluster of requirements covers modularity of the platform and in-vehicle use.

Perception module requirements

The rapid prototyping platform needs to provide radar sensor interface, mono and/or

stereo camera interface, electronic Horizon and ADASIS V2 interface, GPS interface, lidar

and laser scanner interface, ultrasonic sensor interface, C2x interface (WLAN), FPGA

module, integrated (embedded) x86 platform, integration of hardware accelerator or

dedicated ASICs, high speed interface between x86 platform and FPGA.

Application platform requirements

The application platform requirements of the rapid prototyping platform address require-

ments for high-speed, low latency communication, processing of vehicle data, vehicle bus

interfaces, real-time ECU interface, embedded controller for real-time processing and

vehicle actuator interface.

Software requirements

SW requirements refer to three areas:

Software environment requirements for the perception module development: EB

Assist ADTF integration (generic sensor interface and development platform),

RTMaps integration (generic sensor interface and development platform) and

module library for perception algorithms.

Software requirements for application module development: model-based design

of application functions (e.g. Matlab/Simulink)

Requirement for cost modelling of System on Chip (SoC): the rapid prototyping

needs to provide means to evaluate different implementation options for the

perception functions.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


FPGA code requirements

The rapid prototyping platform is required to provide a modeling environment for per-

ception functions and FPGA.

6.2.4. Additional requirements for embedded multicore platform with

FPGA (development level 3)

While the main focus of development level 2 is on evaluation of algorithms in real-time

on public roads, thus on ADAS functionalities and use in the DESERVE DAS function

demonstrators, levels 3 (and 4) go significantly ahead in terms of fulfilling “critical”

requirements like AUTOSAR compatibility, SPICE compliance and functional safety (ISO

26262) which are mandatory for industrial use of the platform. Due to limited resources

and limited project duration, these requirements cannot be fully implemented in

DESERVE. Nevertheless all the work done for the “non-industrialized” DESERVE platform

can be (partly) reused or carried over to the industrialized version of the DESERVE

platform (level 4).

The topics safety and reliability of the DESERVE platform are of utmost importance for its

later industrialization. Safety relevant vehicle applications ISO 26262 require fulfilment of

ASIL D requirements. To arrive at ASIL D certifiable vehicle applications, both FMEDA and

detailed safety concept for the DESERVE platform (level 4) are required. An FMEDA for

the multicore processor intended to be used for levels 3 and 4 was made (this document

is company confidential and will only be disclosed for customer projects). The basic

elements of the safety concept with reference to ISO 26262 will be presented later in this

document (chapter 8).

6.3. Key performance indicators (KPI) to validate requirements

Deliverable D6.1.2 [14] describes the validation plan of the DESERVE project. During the

development process of DAS applications several phases have to be completed. DESERVE

is structured by four main development phases which are described in D1.3.2 “Methods

and Tools Specifications” [4]: (1) Concept, (2) Implementation, (3) Verification and

virtual validation, (4) Integration and on-vehicle validation.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The validation of the DESERVE platform through the evaluation and measurement of the

selected Key Performance Indicators (KPI) should address each development phase. To

identify the most relevant Key Performance Indicators (KPI) for each development phase

of DAS applications (described in section 9.2) is one of the main objectives to be

achieved.

Key Performance Indicators are quantitative or qualitative measurements, agreed on

beforehand, expressed as percentage, index, rates or other value, which is monitored at

regular or irregular intervals and can be compared with one or more criteria.

These are mainly divided in two categories: Quantitative (objective) and Qualitative

(subjective). A list of the main KPIs is presented in [14], based on target objectives

defined in the Description of Work, general requirements defined in D1.2.1 and the

Research Hypothesis and performance indicators presented in D6.1.1.

Table 4 shows the set of KPIs defined for the DESERVE platform [14]. These are related

to the robustness, maintainability and modularity, in different development phases of the

project.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type

Objective or

Quantitative

Subjective

or

Qualitative

Indicator Description Assessment criteria Development phases

Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

1 S Suitability ADAS feature has to be suitable. Suitability addresses the ability of a system to meet the needs of the end

user and, depending on the specific case, of the specific stakeholder.

Each DESERVE demonstrator has to prove the evidence of suitability.

X X

2 O Reliability ADAS feature has to be reliable. Reliability concerns the probability of

failure, breaks and malfunctioning of the

technology on a given time frame.

Each DESERVE demonstrator has to prove the evidence of reliability (preliminary FMEA/FTA).

Different techniques have been developed through

the years; among the most widely adopted are: • Failure Mode and Effects Analysis (FMEA), an inductive method based on the assessor’s experience in the specific domain and aimed at identifying the most probable failures that might happen in a system, and the related causes and impact. • Fault Tree Analysis (FTA) is a deductive method

based on the reconstruction of the possible chains of events that may lead to an undesired effect, to be represented in a standardised graphic language.

X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type

Objective or Quantitative

Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

3 S Robustness ADAS feature has to be robust. Robustness is the ability of a system to resist change without adapting its initial stable configuration. It is linked to the Material strength , Failures in the field,

hazardousness and Portability in hard ware context, and to the Corruptibility, Vulnerability to damaging user

manipulation and Backup availability from the software point of view.

Each DESERVE demonstrator has to prove the evidence of robustness.

X

4 S Maintainability ADAS feature has to be maintainable. The maintainability index for software is calculated with formulae from lines-of-code measures, McCabe measures and Halstead complexity measures. The availability (and adaptability) of options for growing or improving on current

design of technology have to be considered.

Each DESERVE demonstrator has to prove the evidence of maintainability.

X X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type


Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

5 O SW Modularity The software shall be structured on well defined, independent components such as different teams can work parallely on the same application.

The 33 ADAS applications, identified in DESERVE, share a percentage (>90%) of basic sw-components.

X

6 O SW Reusability The software shall be structured on well defined, atomic components such as ADAS applications in a features roadmap can reuse basic software.

The 33 ADAS applications, identified in DESERVE, share a percentage (>90%) of basic sw-components.

X

7 O SW Architecture

Standard

The software architecture should be

compatible with the AUTOSAR (AUTomotive Open System ARchitecture) standard.

Fully implementation of AUTOSAR is not foreseen in

DESERVE. Implementation Cluster Conformance Class verified following the methodology defined within AUTOSAR: - ICC1 : RTE+BSW in one single cluster (min level) - ICC2: RTE+BSW bundled into separate clusters (intermediate level) - ICC3: RTE+all BSW modules separately (max level)

X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type


Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

8 S SW Development Process Standard

The software development should be compliant with ISO/IEC 15504 Information technology — Process assessment, also known as SPICE (Software Process Improvement and

Capability Determination).

At least 3 on the 9 process attributes (performance, management, workproduct, definition, deployment, measurement, control, innovation, optimisation) are assessed on "partially achieved" rating scale.

X X X X

9 S ISO26262 SW Compliance

The software development of safety critical systems should be compliant to

ISO26262 standard. Part 6 of the standard specifically addresses product

development at the software level.

Sw architecture and Sw components design of safety critical ADAS applications should be formally verified.

X

10 S Platform independence and portability

Application software is independent from processing HW.

Each DESERVE demonstrator has to prove the evidence of separation between application and "hw-infrastructure".

X X

11 S Standardized

Sw interfaces

Software components are defined with

standardized interfaces reducing as much as possible the dependency from sensing and controls.

Each DESERVE demonstrator has to prove the

evidence of separation between application and "sensing/actuation infrastructure".

X X X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type


Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

12 S Operating system independence

The perception modules are implemented in a programming language which is independent from the operating system.

Each DESERVE demonstrator has to prove the evidence of separation between programming language and operating system.

X

13 O Programming Language

Software is implemented in a compiled programming language.

Each DESERVE demonstrator has to prove the evidence of implementation in a compiled programming language. At least a percentage of sw (>90%) is implemented in a compiled programming

language.

X

14 O SW version / SW licenses

The Perception Platform delivers information about the SW version currently running. The description of the Perception Platform should include the list of the SW licenses necessary to run the system.

Each DESERVE demonstrator has to prove the evidence of Sw version/Sw license used.

X

15 S Communication technologies independence

Application software is independent from the communication technologies used to interface different on-board units (ECU).

Each DESERVE demonstrator has to prove the evidence of independency between ECU's application and communication technologies.

X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type


Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

16 O Automatic start-up/ Automatic shut-down

It should be possible to automatically start-up the perception platform, without operator intervention. It should be possible to shut down the perception platform in a proper way by sending a

defined shut-down message and removing power supply after a defined shut-down time.

Each DESERVE demonstrator has to prove the evidence of automatic start-up/start-down sequences.

X X

17 S Configuration of sensors position

Position and orientation of sensors mounting on the vehicle are configured

(configuration file) based on the reference perception platform’s predefined coordinate system for each sensor.

Each sensor used on DESERVE demonstrator has to prove the evidence of configuration based on the

reference perception platform’s predefined coordinate system.

X X


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


ID Type


Subjective

or Qualitative


Concept

Imple

menta

tion

Verification &

Validation

Inte

gra

tion &

Validation

18 O Cost Before to release an ADAS application on the market it is necessary to separate the costs which are directly related to the use of the technology (e.g.: fuel vs. Electricity consumption or saving) from

the overall development cost (e.g.: total person-time spent on developing the technology). The overall development

costs have to consider the reduction of the time due to the sw modularity and reusability.

Each DESERVE demonstrator has to estimate both technology and development costs. In particular a percentage of time reduction for the development of application has to be measured.

X X

Table 4: Key performance Indicators and assessment criteria ([14])


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


7. DESERVE platform specification and architecture

Subsequent to the derivation of generic DESERVE platform requirements (section 3), the

requirements were translated into specifications, which represent the starting point for

the development of modules for the DESERVE platform. The specifications were included

into an Excel file which is accessible to all project partners via the project server. By

means of an iterative process, both specifications and software design were refined and

improved. A summary of the specification approach and of the specifications derived from

the DESERVE platform requirements is provided in deliverable D1.3.1 [3].

7.1. DESERVE platform specification

The specifications of each software module have been defined using the same template

(see Figure 23 with definition of units, numbers of bits, signal type, parameter range and

accuracy) and verifying the correspondence (number and kind of parameters) between

the input and output of all possible linked modules. The definition of number of bit and

signal type of each parameter has been chosen according to its range and accuracy and

considering optimization of the memory occupation.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 23: Specification template

Just to provide one example for the specification result, Figure 24 presents the specifica-

tions of longitude, latitude and altitude of a shape point. This specification refers to the

perception platform, module ADASIS (electronic horizon).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 24: Pieces of ADASIS specifications of the DESERVE platform perception

module


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


7.2. DESERVE platform architecture

The architecture of the DESERVE development platform shall follow both the principle of

standard DAS development cycles and the mappings of application building blocks to

final, often heterogeneous hardware implementations. To date there is no tool or

framework available that covers both requirements at the same time on the same

platform.

In the early concept and implementation phase the basic development, specification and

validation (e.g. with MIL, SIL or HIL) is often done with another development framework

(both for SW and HW) than the one applied for the final target platform. Little is known

or taken into account from the final embedded system characteristics when first

application algorithms are programmed and very often the SW modules written in this

first development environment have to be reprogrammed from the scratch when porting

it to the embedded system on chip. If the software, mostly written in a high-level

programming language, finally fits the target system one has selected for series

production, is a game of pure chance and not rarely during the series product

development cycle a larger target system or some “add-ons” have to be chosen. With the

new design space exploration methodology the certainty to select the suitable embedded

target system at first time is significantly increased.

The DESERVE development platform architecture has to comply with the following basic

needs:

Enough flexibility to encompass different development environments in a

common, seamless framework for both the high-level algorithm development and

the easy porting of these SW modules to the embedded target platform.

Real time recording and playback capabilities for both the high-level and

embedded system implementations.

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


A seamless interoperability and replacement between the high-level (i.e. PC-

based) and embedded target systems both for development and validation

purposes.

Figure 25: DESERVE platform (e.g. for development level 2 - rapid prototyping

system based on mixed PC and embedded controller framework)

The basic idea and intention of this hardware architecture is to standardize the interfaces

between the three different development concept levels as good as possible. Inputs from

proprietary ADAS sensor systems and information sources are analyzed via a generic

interface no. 1 to the PC based development environment. Here the ADTF tool with its

filter programming concept is used to develop or improve SW modules on a high-level

programming language. The partitioning and optimization of parts of the SW modules is

consecutively done by shifting such portions over the generic interface no. 2 to the

embedded controller framework 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 no. 3 by applying the same bypassing concept.

Especially computationally intensive tasks can so be “outsourced”, so that even the PC-

based platform is capable to keep the stringent real-time constraints.

Depending on the performance of the PC either all or only specific parts of the SW

modules can be executed there. During the development process more and more SW

parts are transferred to the HW-Accelerator level, which, in the final development stage,


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


results in the next generation embedded ADAS target system. At this last development

step, the level 1 (PC) and level 2 (embedded controller) platform will only serve as a

shell to keep up the overall development framework.

Reuse of already existing components from former ADAS generations may be used in the

early development phase as HW accelerators for computational intensive calculations.

Mainly standard algorithms that are fixed and receive no further modifications are

preferred candidates for such specific HW accelerators.

This section summarizes the DESERVE platform architecture aspects. It considers hard-

and software architecture aspects. The platform architecture is described in detail in

deliverable D25.2 [10].

7.2.1. 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 was 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 is flexible enough for different DESERVE partners to

make different implementations. These would be of forms that might in future be


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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

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:

Figure 26: DESERVE approach – use of common platform for all ADAS modules

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.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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.

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 common parts. They are roughly grouped

around the DESERVE 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).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


7.2.2. Software architecture

As for hardware architecture, the characteristics and constraints that the software archi-

tecture has to fulfill to accept an application based on modules developed inside the

DESERVE platform (Figure 27) were identified. AUTOSAR standards were considered1.

Figure 27: DESERVE platform architecture

1 Note: Being a research project, the development work conducted in DESERVE is dis-

charged from being fully compliant with the AUTOSAR standard. Where possible and easy

to implement, inputs from AUTOSAR were considered, of course. A mandatory request

for AUTOSAR compliance is, however, not up for discussion.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The key architecture challenges are:

AUTOSAR Standards Architecture for the full platform system including perfor-

mance accelerators

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.

Specification of the software architecture

The hardware architecture needs an accompanying 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 28 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.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 28: 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 target platforms of develop-

ment 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 development level 2 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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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.

In Figure 29 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

can be also drawn out of Figure 29. The application layer with dedicated API functions is

essential for program abstraction and separation from the physical hardware peculiari-

ties.

Figure 29: OSI seven layer model for computer network communication


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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.

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.

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-


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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 or instantiation of

components / number of instances.

Figure 30: Overview on the principles of virtual interaction using the AUTOSAR

The middle level, VFB (Figure 30), 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

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


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.

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. 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 D1.3.2 [4]). Moreover, they take

advantage of multi-processor architecture for more computing power.

Based on the Development Platform Requirements [2], 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.

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


be consumed by the algorithmic part of the application. Availability of an AURIX2 DSP

optimized algorithm contributes to high performance execution and significant reduction

of application development time.

7.3. DESERVE platform interface definition

The definition of the DESERVE interface architecture is described together with state of

the art ADAS interfaces and next generation interfaces in deliverable D2.5.4 [11]. Due to

the high relevance of the interface architecture for the DESERVE platform concept, a brief

description is included in the next paragraphs.

7.3.1. Definition of DESERVE interface architecture

The definitions of the interface architecture plays a central role for the communication

and data exchange between the different DESERVE platform modules and sensor compo-

nents. In the DESERVE deliverable D2.2.1 [37] the abstracted interface descriptors are

already defined on a content-based hierarchical level. With standardized information data

flow between the numerous platform modules both the development time and the exten-

sion in performance and scope of the encapsulated modules can be realized very

efficiently and in a well-structured way.

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The architecture of the interface has to be defined individually for each of the existing

OSI layers, starting from the physical layer up to the application layer. Taking the OSI

model for computer networks as starting point, the following DESERVE layers can be

defined:

1) Physical data layer

In this layer the physical structure of the sensor component or communication

unit is concerned. Often proprietary data structures for connecting the sensors or

actuators exist and need to be taken into consideration. Depending on whether

raw signal streams will be transferred or already condensed and preprocessed

data, the transfer rate may vary from a few hundred bits up to several Gigabits

per second. A back-channel for sensor calibration and setup is almost always

required and has to be foreseen.

2) Communication layer

The DESERVE communication layer includes the data link, network and transport

layer and contains all the necessary information on how the data will be sent over

the link between the platform modules and components. Package based protocols

like TCP/IP or UDP are the favorite protocol types to be used for the

communication. However, also proprietary or recently developed bus standards

like Thunderbolt (PCI-Express based active interface link) or the USB-3.0 serial

bus may be used in addition to the Ethernet bus protocol.

3) Application service layer

This is the highest level that establishes the abstracted data link to the user appli-

cations. Similar to the TCP/IP protocol the session layer (responsible for synchro-

nization and logical port mapping) and the presentation layer (syntax layer for

data conversion and encryption) are merged (or better omitted, if not needed) in

the application layer. Bi-directional point-to-point connections between the upper-

level modules and the sensor units occur with a data flow and format as depicted

in Figure 31.

For modules that only communicate within the same hardware unit the physical data and

communication layer are no longer needed. Instead, a message box oriented data trans-


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


fer link is proposed for usage in the DESERVE project. The data to be transmitted is

written in a predefined message box descriptor field and message flags trigger the

synchronization and data updates in the concerned modules. The message box principle

is sketched in Figure 32.

Figure 31: Data flow for a peer-to-peer connection over a physical link

Figure 32: Message box principle for intra-unit communication

Finally, the interfacing concept of the AUTOSAR standard is considered and incorporated

in the DESERVE platform where useful and appropriate. The AUTOSAR mode of opera-

Process/

Application

Process/

Application

Data

Message box Message box

Data Data

Message Message

Message

HeaderFlags


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


tion, as depicted in Figure 33, fits already quite well with the general DESERVE approach

proposed in this document.

In order to achieve a good reusability of embedded software functions, it has proven to

be efficient in the industry to separate the "function software" from parameters defining

the behavior of the software (= calibration data). This allows generating embedded

systems with generic software functionalities by "embedded systems suppliers" (e.g.

Continental, Bosch or others). Such systems are bought by OEMs for building their ADAS

systems. The OEM can adapt the generic function to the individual behavior significant for

his customers "just by calibration". In this process via an application system (market

leader is INCA for example), the calibration data can be changed while the embedded

system is running - regardless if simulated on a PC or running already on the target

hardware.

Figure 33: AUTOSAR Application software concept

In engine control units, for instance, it is used the ASAM standard ASAP2 [39] in order to

describe the calibration parameters. This allows the access of the application system to

access and to change such defined calibration parameters while the software is running

AUTOSAR Application Software

WPII-10.3

Chassis

VFB (Virtual Function Bus)

WPII-10.1

Body Electronics

WPII-10.2

Powertrain

WPII-10.4

Occupant & Pedestrian Safety

WPII-10.5

Multimedia Telematics

HMI

WPII-10.3 Chassis

Electronic

Stability Control

Esc

(Adapt.) Cruise

Control

CrsCtrlAndAcc

Standstill

Management

Ssm

Steering

Steer

Suspension

Susp

Drivetrain

Torque Distrib.

DtTqDibtn

Tire Pressure

Monitoring

TirePMon

Electric Parking

Brake

Epb

Vehicle

Longit. Control

Vlc

Roll Stability

Control

Rsc

Steering VSSSteerVehStabySys

Steering DASSteerDrvrAsscSys

Surroundings

SensorsSurroundingsSnsr

Chassis

Sensors

ChassisSnsr


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


in order to reduce the adaptation work to different hardware or application tasks (e.g.:

other camera, other vehicle, other driver demands) just by changing the input maps,

input curves or values of the function software. This split of function development work

(e.g. done by BOSCH) and calibration work (e.g. done by the OEM) has proven to be

highly efficient also for other embedded mechatronic systems (e.g. for transmission

control units and meanwhile also for active suspension control units) in order to reduce

software versions or releases and to reuse function code.

The separation of calibration date and function software is also allowed according to the

AUTOSAR concept.

7.3.2. Existing ADAS interfaces

All electronic embedded systems used to control vehicle functions (specifically ADAS)

need communications networks and protocols to manage all the process information. The

modules receive input information from a network of sensors (e.g. for engine speed,

lasers, cameras, etc.) and send commands to the control stage (Application platform in

DESERVE), and finally to the actuators or warning systems that execute the commands

(IWI platform) [2].

Due to the increasing complexity of modern ADAS applications, point-to-point wiring has

been replaced by multiple networks and communications protocols. These protocols use

different physical media to provide safe connection among components on the vehicle.

These include single wires, twisted wire pairs, optical fiber cables, and communication

over the vehicle’s power lines.

Communication protocols

Some of the most known and used communication protocols and standards used in

nowadays vehicles are:

CAN (controller area network): it is a cheap (and most used) low-speed multi-

master broadcast serial bus standard (developed by Bosch). The CAN bus is

designed to allow electronic control units (ECUs), microcontrollers and devices to

communicate with each other within a vehicle without a host computer. It’s a

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


message-based protocol, specifically designed for automotive applications but

now also used in other areas such as aerospace, industrial automation and

medical equipment.

VAN (vehicle area network): it is similar to CAN but not widely used. It was

developed by PSA Peugeot Citroën and Renault.

FlexRay: it is a protocol used for general-purpose. It has high-speed protocol to

support time triggered architecture and fault-tolerance property.

LIN (local interconnect network): it is a low-cost in-vehicle sub-network, used

mainly by some European vehicle manufacturers. Some features are: Guaranteed

latency times, variable length of data frame (2, 4 and 8 byte), configuration

flexibility, etc.

SAE-J1939 and ISO 11783: an adaptation of CAN for agricultural and commercial

vehicles. It is also used for diagnostics among vehicle components.

MOST (Media-Oriented Systems Transport): it is a high-speed multimedia that

supports user applications such as GPS, radios, and video players. It can be used

for multimedia applications inside or outside the car.

Keyword Protocol 2000 (KWP2000): it is a protocol for automotive diagnostic

devices. It can run in serial line or over CAN.

Other protocols used are: DC-BUS, IDB-1394, SMARTwireX, SAE-J1850, SAE-J1708,

SAE-J1587 and ISO-9141-I/-II.

Recent vehicles have installed multiple networks (with different protocols) to communi-

cate among electronic control units (ECU) onboard. The networks are isolated from one

another for several reasons, including bandwidth and integration concerns.

Existing interface standards

Current ADAS systems are designed and built to provide a dedicated answer to specific

functionalities as: Lane Departure Warning, Pedestrian Detection, Blind Spot Detection,

Emergency Braking,... .

Most ADAS are including in the same box the sensor itself and the processing unit. So,

the raw data provided by the sensor (camera, radar) are directly loaded inside the ECU

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

http://en.wikipedia.org/wiki/PSA_Peugeot_Citro%C3%ABn

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


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


unit and processed. Only high level (processed) information is available on the

communication buses. Raw data (e.g. pixel information of images) is not available.

The ADAS modules are dedicated products which communicate mainly within the same

hardware unit. Nevertheless, to adjust the algorithms in function of the vehicle status,

it’s necessary to provide the ADAS modules with some vehicle information as: speed,

yaw rate, direction indicator status...

To manage the vehicle information acquisition and sending of the outputs, various com-

munication interfaces are available, depending on the product:

CAN communication interface

FlexRay communication interface

The CAN Bus interface uses an asynchronous transmission scheme controlled by start

and stop bits at the beginning and the end of each character. This interface is used,

employing serial binary interchange. Information is passed from transmitters to receivers

in a data frame. Different data rates are defined and the cable length depends on the

data rate used. The maximum data rate is 1Mbps (cable length max: 40 m), the lower

rate is 10kbps (cable length max: 1 km)

FlexRay is also an automotive network communications protocol; it is designed to provide

high–speed deterministic distributed control for advanced automotive applications, to

govern on-board automotive computing. It is faster and more reliable compared to CAN,

but also more expensive.

FlexRay’s dual channel architecture offers system–wide redundancy that supports the

reliability requirements of safety related systems. With a data rate of 10 Mbit/s per

channel, the FlexRay system can also be employed as a vehicle–wide network backbone,

working in conjunction with other communication systems like CAN and LIN. It can be

used to reduce the number of parallel CAN networks used to solve bandwidth bottle-

necks.

Nevertheless, during the development step even the FlexRay bandwidths aren’t suffi-

cient. It is necessary to record a lot of data useful to develop, improve, test and to

validate for instance ADAS functionalities: the sensor raw data (image of the camera),


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


vehicle information data, some intermediate data (optical flow, disparity map, ...) and of

course the results data. All those data must be synchronized and recorded in real time,

the bandwidth is really more important than the FlexRay capabilities.

For this reason, specific electronics (based on the Ethernet communication) and software

(similar as ADTF, RTMaps ...) have been developed and integrated to record, in real time,

these data. On some products up to 4 Ethernet connections are integrated to transfer the

data until the recorder unit (dedicated PC).

The communication bandwidth requirements increase more and more with more and

more complex applications, the existing network are not specified to cover the increasing

demands for bandwidth, and the Ethernet price. The Ethernet seems to be an alternative

to the existing communication hardware.

7.3.3. Definition of next generation interfaces

The definition of next generation high speed sensor interfaces is the key to enable the

improvement for next generation driver assistant systems. An optimized interface leads

to optimized dataflow and system performance. For each sensor family (Camera/RADAR)

there is a dedicated interfacing needed.

a) Parallel camera interface (CIF)

The Camera Interface (CIF) represents a complete video and still picture input interface

transferring data from an image sensor into video memory. Furthermore, several hard-

ware blocks - performing image processing operations on the incoming data - are

provided (Figure 34).


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 34: Camera Interface (CIF) overview

Camera Interface Functional Overview

Apart from providing the physical interfacing to various types of camera sensor modules,

the CIF block implements image processing and encoding functionalities. The integrated

image processing unit supports image sensors with integrated YCbCr processing.

Additionally, the CIF also supports the transfer of RAW (e.g. Bayer Pattern) images and

non-frame synchronized data packets. The CIF block features a 16 bit parallel interface.

All output data are transmitted via the memory interface to a BBB (Back Bone Bus)

system using the master interface. Programming of the CIF is done by register read/write

transactions using a BBB slave interface.

The CIF provides a sensor/camera interface for a wide variety of video applications and it

is optimized for high speed data transmission under terms of low power consumption.

This module is designed to be used for the following use cases:

Video capturing/encoding

Still image capturing in YCbCr with on-the-fly JPEG encoding

RAW frame data capturing

The CIF requires fast system memory for image storage in either planar, semi-planar or

interleaved YCbCr or RAW planar format or as JPEG compressed data. The iJPEG

encoding engine should be able to generate a full JFIF 1.02 compliant JPEG file that can

be displayed directly by any image viewer. Important YCbCr formats - which are used for


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


video compression (e.g. MPEG4) for instance - are supported. For on-the-fly encoding

macro block line interrupts are generated to trigger video encoding. The following list

summarizes the targeted CIF’s features:

Throughput up to 96 MPixel/s

32-bit Back Bone Bus (BBB) slave programming interface

BBB master interface

ITU-R BT 601 compliant video interface supporting YCbCr and RAW data transfer

ITU-R BT 656 compliant video interface supporting YCbCr and RAW data transfer

Non line/frame aligned data transfer (data mode)

16-bit parallel camera interface

YCbCr 4:2:2 processing

Hardware JPEG encoder (supporting images up to a horizontal resolution of 1280

pixel) incl. JFIF1.02 stream generator and programmable quantization and

Huffman tables

Windowing and frame synchronization

1 Main and 5 Extra Image Cropping units allowing parallel transfer and position

adjustment of up to 6 sub regions

Path from Main Image Stabilization or from one Extra Image Cropping unit to

debug interface including a Metasymbol Generation unit inserting frame start and

timing information into the stream

Programmable watchdog timer to detect abortion/breaks in frame transmission

Linear downscaling for the first extra path, supporting a mode for RGB Bayer

Pattern

Frame skip support for video (e.g. MPEG-4) encoding

Macro block line, frame end, capture error, data loss interrupts and synchroniza-

tion (h_start, v_start) interrupts

Programmable polarity for synchronization signals

Luminance/chrominance and chrominance blue/red swapping for YCbCr input

signals

Maximum input resolution of 4095x4095 pixels


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Buffer in the video memory organized as ring-buffer, supporting up to 2x8 Beat

Bursts (2x32 Bytes)

Buffer overflow protection for RAW data transfer and JPEG files

Asynchronous reset input, software reset for the entire IP and separate software

resets for all sub-modules

Support of planar, semi planar and interleaved storage format (main path)

Power management by software controlled clock disabling of currently not needed

sub-modules

b) Serial RADAR interface (RIF)

Analog-to-digital converter (ADC) sample rates have been increasing steadily for years to

accommodate newer bandwidth-hungry applications in communication, instrumentation,

and consumer markets. Coupled with the need to digitize signals early in the signal chain

to take advantage of digital signal processing techniques, this has motivated the deve-

lopment of high-speed ADC cores that can digitize at clock rates higher than 100 MHz to

200 MHz with 8 to 12 bit resolution.

In standalone converters, the ADC needs to be able to drive receiving logic and accom-

panying PCB trace capacitance. Current switching transients due to driving the load can

couple back to the ADC analog front end, adversely affecting performance. One approach

to minimize this effect has been to provide the output data at one-half the clock rate by

multiplexing two output ports, reducing required edge rates, and increasing available

settling time between switching instants.

Use of LVDS for ADC high speed data output

A new approach to providing high-speed data outputs while minimizing performance

limitations in ADC applications is the use of LVDS (low voltage differential signaling).

Infineon is incorporating LVDS output capability in new RF devices ADCs—and will include

LVDS input capability in its new micro-controller designs.

LVDS is, as the name says, a low voltage differential signaling scheme. The operative

words here are low voltage (~350 mV) and differential. Standards bodies have developed

specifications that will be discussed later in this note. Lower voltage signal swings have


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


the intrinsic advantage of shorter switching times as well as reduced EMI concerns

(adjacent differential traces tend to cancel each other’s EMI).

Differential signaling also has the well-known common-mode rejection benefit. Noise that

is coupled to the signals tends to be common to both signal paths and cancelled out by a

well-designed differential receiver. LVDS outputs are current output stages requiring a

100 Ohm terminating resistor at the receiver, differing from CMOS outputs that generally

do not require termination. The current output results in a fixed dc load current on the

output supplies (Figure 35) - avoiding current spikes on the supply that can couple to the

sensitive analog front end.

Figure 35: Output termination in LVDS connections

Standards

Two standards have been written to define LVDS. One is the ANSI/TIA/EIA-644 which is

titled, ”Electrical Characteristics of Low Voltage Differential Signaling (LVDS) Interface

Circuits.” The other is IEEE Standard 1596.3 which is titled, ”IEEE Standard for Low-

Voltage Differential Signals (LVDS) for Scalable Coherent Interface (SCI).” A brief

summary of these two standards is provided below.

ANSI/TIA/EIA-644

The ANSI/TIA/EIA Standard was developed under the Telecommunications

Industry Association (TIA) Subcommittee TR-30.2 and contains only generic

electrical specifications for LVDS. Its purpose was to create a general high-speed

interface standard for use in point-to-point connections between data

communications equipment. The maximum data signaling rate is 655Mbps. The


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


TIA Subcommittee intended other standards bodies to reference ANSI/TIA/EIA-

644 in more complete interface specifications between transmitters and receivers.

IEEE Standard 1596.3

The IEEE Standard 1596.3 was developed as an extension to the 1992 SCI

protocol (IEEE Standard 1596-1992). The original SCI protocol was suitable for

high-speed packet transmissions in high-end computing and used ECL levels.

However, for low-end and power-sensitive applications, a new standard was

needed. LVDS signals were chosen because the voltage swing is smaller than that

of ECL outputs, allowing for lower power supplies in power-sensitive designs.

c) Generic interface to communicate between ADTF project and FPGA based

hardware platform

In order to allow an easy and standard communication between an ADTF-Project and the

FPGA-based hardware platform, a generic interface is used. The generic interface realizes

the communication with different processing elements implemented in the FPGA-based

hardware platform transparent to the user. The general communication method is shown

in Figure 36. As a proposal for the link between ADTF and the FPGA-based hardware

platform, a Gigabit Ethernet interface can be used.

Figure 36: Communication between ADTF on host pc and processing elements

implemented on the FPGA-based hardware platform

An exemplary implementation of a Gigabit Ethernet connection between ADTF and an

FPGA development board was created and evaluated [38]. The communication scheme,

which is depicted in Figure 37, is very similar to the structure shown in Figure 36. A host


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


PC is running the ADTF software and serving as an interface to different sensors. It sends

data via an Ethernet link to the FPGA board. Data can be written to the processing

elements (PE) directly. Additionally, bigger amounts of data can be written to the FPGA

board’s memory.

This implementation has been evaluated with a case study (see [38] for details) and it

has been shown, that the simulation time of a complex application can be reduced by a

factor of 65 in this application. Therefore the algorithmic evaluation and parameter space

exploration is accelerated significantly.

Host PC

ADTF

FPGA

MAC PE

PE

ETHSensor

Sensor MEM

Figure 37: Implemented Gigabit Ethernet Interface between ADTF and an FPGA

development board

8. Safety standards and certification concepts

Some concepts related to modular certification have already been adopted by current

standards and thus have found their way into the state of the practice. This is particularly

true for the fields of automotive systems because the trend towards modularized archi-

tectures has been particularly strong in this field.

8.1. Safety impact of DESERVE

Modularisation of a common ADAS platform comes with a clear impact on safety. Modules

will interact, for example on Missed Trigger Interaction, Shared Trigger Interaction, Se-

quential Action Interaction and/or Looping Interaction.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Module interaction implies that any change in operation of one module (feature) can be

attributed in part or in whole to the presence of any other module (feature) in the

operational environment, as illustrated in the figure below.

Figure 38: Module interaction implies changes in system behavior

8.2. Functional safety of road vehicles (ISO 26262)

The international standard ISO 26262 for the functional safety of street vehicles contains

the so-called concept of Safety Element out of Context (SEooC). A SEooC is defined as a

component for which there is no single predestinated application in a specific system.

Therefore, the SEooC developer does not know the concrete role the product has to play

in the safety concept. Sub-systems, hardware components, and software components

may be developed as SEooCs. Typical software SEooCs are reusable, application

independent components such as operating systems, libraries, or middleware in general.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


For SEooC development, the standard suggests specifying assumed safety requirements

and developing the system according to these requirements. When the SEooC is to be

used in a specific system, the system developer has to specify the demanded require-

ments, which can subsequently be checked against the assumed requirements. If there is

a match between the demanded and the guaranteed (assumed) requirements, system

and component are compatible.

The standard does not provide any suggestions or methods on how to identify safety

requirements such as to increase the chance that assumed and real requirements will

actually match. The standard specifies a relatively coarse-grained process for embedding

a SEooC development into the standard’s safety lifecycle. This approach deals with

hierarchical modularization since it focuses on the SEooC’s role as a sub-component of a

system.

In general, integration of the SEooC is expected to be done at development time and

thus there is no explicit support for open systems where components are to be integrated

dynamically.

8.3. Guidelines related to ISO26262

ISO 26262 is a derivative of IEC 61508, the generic functional safety standard for

electrical and electronic (E/E) systems. Ten volumes make up ISO 26262. It is designed

for series production cars, and contains sections specific for management, concept and

development phase, production, operation, service and decommission.

The ISO 26262 requires the application of a “functional safety approach”, starting from

the preliminary vehicle development phases and continuing throughout the whole

product lifecycle.

The DESERVE project focuses on the concept and development (at system, hardware and

software level) phases of the lifecycle. During these phases, the main steps defined by

the Standard are:


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Item definition: the Item has to be identified and described. To have a satisfactory

understanding of the item, it is necessary to know about its functionality, interfaces, and

any relevant environmental conditions.

Hazard analysis and risk assessment: to evaluate the risk associated with the item under

safety analysis, a risk assessment is required. The risk assessment considers the func-

tionality of the item and a relevant set of scenarios. This step produces the ASIL (Auto-

motive Safety Integrity Level) level and the top level safety requirements.

The ASIL is one of the key concepts in the ISO 26262. The intended functions of the

system are analyzed with respect to possible hazards. The ASIL asks the question: “If a

failure arises, what will happen to the driver and to associated road users?".

The risk of each hazardous event is evaluated on the basis of:

Frequency of the situation (or “exposure”)

Impact of possible damage (or “severity”)

Controllability

The ASIL level is standardized in the scale:

QM: quality management, no-risk

A, B, C, D: increasing risk with D being the most demanding.

The ASIL shall be determined without taking into account the technologies used in the

system. It is purely based on the harm to the driver and to the other road users.

Identification of technical safety requirements: the top level safety requirements are

detailed and allocated to system components.

Identification of Software and Hardware safety requirements: The technical safety

requirements are divided into hardware and software safety requirements. The

specification of the software safety requirements considers constraints of the hardware

and the impact of these constraints on the software.

To take into account the functional safety approach, the DESERVE applications should

consider the application of the following main points:


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


1. Analyze risk early in the development process

2. Establish the appropriate safety requirements

3. Consider these requirements in software and hardware development

The impact of the standard is different for the development of warning functions, control

functions or automated driving functions.

8.4. Safety and AUTOSAR

In the automotive domain, Östberg and Bengtsson [50] propose an extension to

AUTomotive Open System Architecture (AUTOSAR) which consists of a safety manager

that actively enforces the safety rules described in dynamic safety contracts. Their main

contribution is a conceptual model of safety architecture suitable for runtime based

safety assessment. Openness and Adaptivity were both addressed.

Also in the automotive domain, Frtunikj et. Al. [51] present a runtime qualitative safety

assessment that considers Automotive Safety Integrity Level (ASIL) and its

decompositions in open automotive systems. In their solution, the authors consider the

modularization of safety-assessment using Safety Elements out of Context (SEooC) from

ISO26262. In their approach, the SEooC was extended and the safety-assessment is

done at runtime by a Safety Manager component.

8.5. Safety mechanisms for DESERVE platform

As an example, this paragraph summarizes some features of the safety mechanisms that

are available by Infineon’s multi-core platform AURIX which represents a potential

instance of DESERVE platform (development level 3). Its safety documentation includes:

Safety case report providing the arguments with evidence that the objectives of

the ISO26262 and the safety requirements for a component are complete and

satisfactory.

FMEDA (customer and Infineon proprietary document)

Safety manual including an overview of the assumed application use cases and

guidance for the application level, a summary of safety features and mechanisms


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


and their recommended use as well as the summary of achieved safety metrics

and resulting ASIL compliance [40].

Figure 39: SEooC safety mechanisms

The AURIX microcontroller platform is developed as a SEooC (Safety Element out of

Context) and provides the safety mechanisms summarized in Figure 39. It provides a

Safe Computation Backbone compliant with ISO 26262 ASIL D (this includes Single Point

Fault Metric fully supported by HW mechanisms and Latent Fault Metric supported by SW

(SafeTlib), Logic MIST, MBIST). Support criteria for coexistence of elements are enabled

through a layered protection system (covering CPU tasks, Shared Memories, Peripherals),

CPU supervisor/user privileges, Safety Task Attribute and a rich set of counters &

watchdogs for program flow & temporal monitoring. SEooC deliverables are the Safety

Library (SafeTlib), Safety Manual to support SEooC integration and FMEDA to support

computation of the ISO 26262 Metrics.

environment

Sensor

Cluster

Interface

Element(s)

Acq

uis

itio

n

Pe

rip

he

rals

Safe

Computation

CommunicationA

ctu

atio

n

Pe

rip

he

rals

Interface

Element(s)Actuator

environment

Sensor

Cluster

Interface

Element(s)

diagnostics

diagnostics

Independent Safety

Controller

Safe

State

SEooC

Fault

State

Communication Network(s)

SEooC

SEooC

Common

Cause

Monitoring

Safe Computation

Safe Aquisition

Safe Actuation

Safe Communication


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Top Level Safety Requirements (TLSR) related to the Microcontroller I/O sub-system are

specified by the system integrator, as these vary for each application. TLSR1 (ASIL D)

requires to avoid false output of the microcontroller for longer than the FTTI (Fault

Tolerance Time Interval, Figure 40), while TLSR2 (ASIL B) only require to avoid

unavailability of a safety mechanism for longer than one driving cycle.

Figure 40: Top level safety requirements

The Fault Tolerant Time Interval is more precisely defined by Figure 41. The application

dependent fault detection time worst case is the diagnostic time interval. The fault

detection time depends on the safety mechanism. The fault reaction time is the sum of

failure signaling time and failure reaction time. Failure signaling time depends on the

microcontroller architecture, while failure reaction time depends on the application. The

failure signaling time is composed by the alarm forwarding time plus the alarm

processing time plus the failure signaling time.

Output

Element

Microcontroller

Safety

Supervision

watchdog

Output

Element

Safe State Reporting

Output

Element

Input

Element

Se

co

nd

ary

Sa

fe S

tate

Co

ntr

ol

Actu

ato

r S

ub

syste

m

Vital Parts

Safety

Mechanisms

Mo

nit

ors

Fault Tolerance Time Interval (FTTI)

How long can an element tolerate an

incorrect input before its behavior has

the potential to lead to an hasard

Hazard to control (1)

Wrong Output from Microcontroller

à Avoid wrong output for longer then FTTI

Hazard to control (2)

Unavailability of a safety mechanism

à Detect unavailability of a safety measure within

the multiple point fault detection interval

Wrong

Actuator

Output has

the potential

to lead to an

hazard

Application

dependent

Part

Application

dependent

Part


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 41: Fault Tolerant Time Interval (FTTI) definition

Safety requirements

With the AURIX as basis for DESERVE platform realization, it fulfils the targets according

to ISO26262-5, 8.4.5, which defines requirements for ISO26262 metrics. To achieve

ASIL D, for instance, the single point failure metric (SPFM) needs to reach minimum 99%

and the latent fault metric (LFM) needs to reach 90% or above. The minimum values of

SPFM and LFM shall be reached by every vital part. The SPFM threshold levels shall be

reached both for permanent and for transient faults. For a given ADAS application SPFM,

LFM and PMHF (probabilistic metric related to hardware failures) metrics are estimated

based on the vital, critical and application-dependent parts utilization.

In terms of PMHF for ASIL D safety goal, ISO26262-5 requires a metric of less than 10

FIT (failure in time, referring to 10^9 hours). ISO 26262-5 9.4.3.6 and 9.4.3.7 specify

the relationship between ASIL and FCR and DC (Residual Faults). To meet ASIL D

requirements the diagnostic coverage for a FCR5 part shall be > 99.99%. The safety

mechanisms are designed to achieve coverage of 99.99%.

Safety architecture

The safety architecture goal is to provide a safe computation platform for up to ASIL D

safety applications according to ISO26262, as this ASIL level is required for most next

Normaloperation

Safe state

FaultFault detection

Fault detection

time

Fault reaction time

Possible hazard

Fault Tolerant Time Interval


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


generation ADAS. To achieve this level, safe computation hardware and software, safe

operating system as well as safe software architectures are required.

Figure 42: Generic elements of safe computation hardware platform

The generic elements (vital parts) of a safe computation hardware platform are

summarized in Figure 42. Safe CPU requires hardware redundancy, realized by delayed

lockstep CPU with enhanced timing and design diversity. Safe SRAMs allows information

redundancy (realized by standard SECDED ECC, address signatures). Also safe Flash

memory is needed for information redundancy (realized by an enhanced ECC with more

than 99% coverage of arbitrary multiple-bit fault). Enhanced error detection codes for

covering data & addressing faults lead to safe interconnects and support information

redundancy. The clock system frequency range monitors using internal high precision

independent clock source, internal & external watchdogs. Finally power supply range

monitoring is implemented for the internal regulators.

To achieve a safe computation software platform an ASIL D compliant operating system

needs to be used featuring memory protection and time protection. Further it needs to

provide services for program flow monitoring, end-to-end communication safety

protocols as well as safe interrupt vector generation. ASIL D compliant software is

required to be developed according to ISO 26262 part 6.

The AURIX platform ensures freedom of interference at software level by means of SW

isolation, while freedom of interference at hardware level is guaranteed by HW isolation.

Safe Computation HW

Safe CPU

Safe Storage Data (SRAM)

Safe Storage Code (FLASH)

Safe Infrastructure: Voltage Regulators, Clock

Safe Intra-Chip Communication

Freedom of Interference

SW/SW SW/HW HW/HW


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The CPU MPU (memory protection unit) monitors the direct access to the local memories,

applies to software tasks and allows dynamic re-configuration. The bus MPU monitors the

SRAM accesses via interconnect. Finally register access protection monitors write access

rights to module registers.

9. Methodology for application development utilizing the

DESERVE platform

This section focuses on the introduction to the methodology for development of ADAS

functions based on the DESERVE platform. The complete tool-chain may become

heterogeneous and manifold, depending on the scope and possible field of application the

DESERVE platform is intended to be used. The DESERVE platform system may work at

different development stages (see the four levels explained in section 2).

The big challenge is to close the gap between the development phases and to make the

whole development process as seamless and integrated as possible. The DESERVE

development process therefore has to adapt the actual V-model cycle in order to provide

a common environment for design, development and testing of ADAS functions; provide

a common environment for coexistence of ADAS functions and allow the reuse of pre-

validated software components.

9.1. Development process

Consolidated methodologies exist to guide the development process and the validation of

new safety systems. With integration of ADAS it is needed to step beyond the traditional

V-Model-based system engineering. It is needed to establish a consolidated design and

development validation environment where new components can be embedded and

functions can be developed and tested.

Differently from today development phases, individual functions should be designed from

the beginning in such a way that they operate within a common environment, with

shared resources, where the different ADAS functions will not simply “live together”, but


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


coexist and deeply cooperate by providing their assistance to the drivers simultaneously

and in an interrelated way.

Development of new ADAS functions will be done using pre-validated software

components. This software components reuse, in particular about the interpretation of

the vehicle’s surroundings and of the driver behavior, will allow to rapid qualification or

certification of compositionally designed systems and especially rapid re-qualification or

re-certification after change.

Without the need to re-qualify all systems, but only the aspects related to the specific

newly integrated application of ADAS functions, DESERVE platform enables the evolution

of ADAS functions, managing the system complexity, reducing overall costs (fixed and

variable) and improving safety and robustness.

9.2. Development phases of DAS applications

Deliverable D6.1.2 [14] describes the validation plan of the DESERVE project. During the

development process of DAS applications several phases have to be completed. DESERVE

is structured by four main development phases which are described in D1.3.2 “Methods

and Tools Specifications” [4]: (1) Concept, (2) Implementation, (3) Verification and

virtual validation, (4) Integration and on-vehicle validation (see Figure 43).

These main phases can be decomposed in the following development sub-phases:

1. Use-cases definition

2. Requirements definition

3. Software architecture definition

4. Configuration of simulators environments

5. Development of perception and fusion algorithms

6. Development of specific control algorithms

7. MIL Verification & Validation

8. SIL Verification & Validation

9. HIL Verification & Validation

10. Integration on vehicle


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


11. Validation on vehicle

Figure 43: Development phases of DAS applications

Concept phase

The process starts from the Concept phase. Here use-cases of interest and requirements

of the developing DAS function are defined and collected. Needs for standards com-

pliancy (i.e. AUTOSAR) and for Functional Safety (i.e. ISO 26262) have to be considered

in this early phase. Coexistence between ADAS functionalities have to be taken into

account.

The concept phase also includes the definition of the software architecture, and the

mapping of each software component into the hardware architecture defined in the

DESERVE platform (see section 7) and mainly constituted of an embedded HW or PC

running perception and fusion algorithms and a rapid prototyping ECU running control


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


algorithms. The HW architecture could be extended with the introduction of additional

components like sensors and/or actuators.

Standardization of interfaces, communication networks, etc. and the definition of a

modular architecture is the way to improve the re-usability and the robustness of the

DESERVE developed functionalities without continuously re-qualify all systems, but only

the aspects related to the specific integrated application of ADAS functions.

Tools based on UML language have to be integrated into the DESERVE tool chain in order

to achieve these results. Another example is System Desk, a tool which allows defining

SW architectures based on the AUTOSAR standard.

Implementation phase

Starting from requirements defined in the Concept phase two parallel activities of the

Implementation phase can start. The first one refers to the configuration of simulators

environments (Vehicle, Sensors, Scenarios) with the goal to implement the defined use-

cases. The second activity is the development of perception, fusion and specific control

algorithms based on defined HW and SW architectures. In order to realize the

coexistence between ADAS functionalities, this phase have to be developed taking in

account modular architectures and software (pre-validated) components reuse.

The use of simulators in the toolchain for the development of embedded functions has

many advantages:

capability to work offline in a reproducible context;

capability to test situations which are difficult to run in the real-world (dangerous

or rare);

capability to provide a ground truth for perception algorithms validation;

capability to test many different configurations in terms of sensor models,

positions, combinations, etc.

There are various kinds of simulators which can be used in the frame of the DESERVE

project. Mainly three different kinds can be distinguished:

sensors and environment (e.g. Matlab/Simulink, RTMaps, ADTF)


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


vehicle dynamics

real-data playback systems (RTMaps, ADTF)

The second activity is the development of perception, fusion and specific control algo-

rithms based on defined HW and SW architectures. In order to realize the coexistence

between ADAS functionalities, this phase have to be developed taking in account modular

architectures and software (pre-validated) components reuse. Numerous tools are

available (see deliverable D1.3.2 for details), e.g. for the algorithms development,

DESERVE platform supports model-based development process, e.g. by using tools like

as MATLAB/Simulink (including Target Link).

Verification and validation phase

The outputs provided by the implementation activities are used for following Verification

and Validation phase. Here different V&V steps (Model-In-the-Loop, Software-In-the-

Loop and Hardware-In-the-Loop) allow to check requirements compliancy and to provide

robust and safe code. In case of unexpected behaviour or tests failure, the process allows

to update the requests with the objective to modify the output of the implementation

phase or, if necessary, of the concept phase.

The model-based design of ECU software as shown in Figure 44 is increasingly being

used in the automotive industry. Especially with driver assistance systems, this approach

allows engineers to evaluate and verify functional concepts on a PC early in the

development process by means of the so-called model-in-the-loop (MIL) simulation and

to reuse plant models and test libraries in subsequent development stages comprising

software-in-the-loop (SIL) and hardware-in-the-loop (HIL) simulation.

Applying the MIL approach, controller algorithms are developed and implemented by

means of dedicated models that can be simulated in a block diagram environment

providing graphical editors, block libraries and solvers for modeling and simulating

dynamic systems. For closing the control loop suitable plant models are required which

are mathematical representations of the associated system under control. This way MIL

serves as a convenient and cost-efficient method to verify and validate both controller

and plant models in an early development stage on a PC by means of simulation.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 44: Typical process with model-based development

The SIL approach allows the direct integration of control algorithms in terms of target

code in a simulation environment. Typically, the target code is C-code which was

automatically generated, for example, from the controller models designed during MIL

simulation. The target code is connected with plant models and simulated in a closed

loop on the developers PC. The benefit of SIL is that the target code can be simulated

and verified without having the final electronic control unit (ECU) available. Even if the

ECU hardware is not defined yet, developers are able to test the target code in an early

development stage. Software-in-the-loop can thus be viewed as a PC-based method to

verify and validate the actual controller software which is the same code that runs on the

final hardware controller. Therefore, SIL offers the possibility to execute tests before the

hardware is available.

Today, ECU software is typically tested for production use with real-time hardware-in-

the-loop simulators. Here, the plant models are calculated in real-time and they are

connected to the ECU(s), the device(s) under test, via the vehicle bus and dedicated I/O

interfaces. With HIL, the simulation of these components have to be as accurate as it is

required to run the ECU(s) without generating diagnostic trouble codes in the on-board

error memory. Typically, the plant models have to provide mathematical representations

of the related dynamic systems. For example, an HIL simulator for the validation of an

automotive anti-lock braking system may have mathematical representations in the plant


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


model for the vehicle dynamics such as suspension, wheels, tires, road characteristics

and dynamics of the brake system’s hydraulic components.

HIL simulation is a technique that can be applied to the verification of a single ECU

(called component verification, for example for an engine or anti-lock braking ECU) and

for networked ECUs related to a complete system (called system verification or

integration tests). In particular in the ADAS context the associated algorithms are

distributed across several ECUs and the final validation for production use is done by HIL

integration tests. Often also real-vehicle components (real parts, such as the throttle or

injection valves) are connected via their electrical interfaces to the simulator, especially

when the associated component models are not accurate enough for a certain verification

task.

An HIL simulation often also includes electrical emulation of sensors and actuators. These

electrical emulations act as the interface between the plant model and the ECU(s). The

value of each electrically emulated sensor is controlled by the plant model and is read by

the ECU(s). Likewise, the ECU(s) calculate the control algorithms and output actuator

control signals. Changes in the control signals result in changes to variable values in the

plant simulation.

Integration and validation phase

The last phase of DESERVE round-trip is the Integration and Validation on vehicle. DAS

functionality is integrated into the vehicle. Final validation tests are performed. In case of

residual problems, Implementation and/or Concept updates are performed.

The integration on vehicle phase allows verifying and validating the complete HW and SW

system developed. A wide range of tests is performed in order to ensure the ADAS

functionality meets its design requirements. Testing program, for example, has to

evaluate performance, efficiency, and durability, structures and components, environ-

mental capabilities and electromagnetic compatibility.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


9.3. Analytical modelling approach for system on chip concepts

The selection and implementation of an analytical modelling approach for system on chip

concepts is described in deliverable D2.1.4 [8]. Identifying the best software/hardware

implementation of a system can be performed by an iterative process (see Figure 14).

The application designer selects algorithms and defines their parameters. The evaluation

of a hardware mapping of these algorithms indicates whether the hardware meets the

requirements and may lead to new insights or hints to the application designer, regarding

the modification of the application parameters in order to allow a more efficient hardware

realization.

Figure 45: Design space exploration framework in the design flow for

heterogeneous hardware architectures

For a rapid evaluation of hardware platforms, to compare different realizations and to

find the best possible implementation, a design space exploration is needed. The

evaluation of hardware platforms and derivation of associated hardware costs is a

laborious task that can take a long time. To make the design space exploration

practicable, cost models can be employed.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Usually there are many different possible mappings of application building blocks to

hardware (architecture) blocks, as the hardware can be implemented using different

technologies. Considering the different characteristics of these technologies, the

possibility to explore the design space is needed in order to find solutions that meet the

requirements. On the other hand, the evaluation of a software/hardware mapping can

deliver design support at different levels in the design process.

The design space usually is spanned by a huge number of objectives, for example,

implementation cost, power consumption, latency, silicon area, flexibility, etc. It is not

feasible to implement or simulate a variety of different possible hardware realizations for

evaluation and comparison purposes, as the effort would be too high and the simulation

of complex hardware would take a long time. Therefore, a cost evaluation and design

space exploration based on quantitative cost models will be implemented.

The model based cost evaluation supports the system designer by allowing an

exploration of the prevailing design space without the need for deep knowledge of the

hardware technologies. Thus, the system can be analyzed in early design stages and the

feature estimates provided by the cost models can be used to drive the design process.

Different hardware platforms impose their own platform specific requirements for the

same application while working towards fixed design goals. Comparing the models of,

e.g., programmable multicore systems and dedicated hardware, architecture specific

attributes have to be considered. To model programmable multicore processors, the work

distribution and work balance have to be evaluated, data locality, cache accesses and

cache coherency have to be taken into account and the granularity of parallelism is

among many other characteristics an important model component to estimate the non-

deterministic runtime behavior of multicores due to parallel computing. In contrast,

dedicated hardware requires a software model for extracting important algorithmic

parameters, which might have a large impact on the later hardware design. In addition to

a runtime model, a resource estimation for required lookup-tables, number of used

registers and block RAMs and utilized DSPs of the later design is possible.

Design space exploration is composed of the following steps:


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


1. To evaluate the costs of a system, it has to be partitioned into hardware building

blocks that can be described independently by specific parameters. Examples for

such building blocks are image filters with the number of filter coefficients as a

parameter.

2. After specifying the building blocks, a mapping of these blocks to hardware

technologies is performed. This determines the cost models to use for evaluating

the characteristics of the single blocks.

3. A specification of the system, that means, the required characteristics, has to be

fixed. These characteristics could be, for example, maximal power consumption,

maximal silicon area or minimal throughput.

4. The cost models are evaluated to compute the estimated characteristics of the

hardware building blocks.

5. A report describing the evaluated system is generated. It contains the estimated

cost values and indicates, if the system can meet the requirements. From this

report the designers can derive design support for different levels of the design

process.

The design space exploration framework is built on quantitative cost models that describe

different possible hardware implementations of application building blocks. Those cost

models are collected in a model library. For each application building block, the model

library contains a family of cost functions that describes the realization of that building

block on a specific hardware technology. A cost function family itself describes different

characteristics of the specific hardware realization of the building block. These

characteristics include performance (latency), power consumption, and silicon area.

However, the model library is flexible and allows the integration of cost functions for

additional characteristics, for example, implementation cost, flexibility, throughput rate,

etc. The evaluation tool will use all the available cost functions for a basic block.

Different cost models, or cost functions, can be specified in different ways. The system

will at least operate on the following types:

A cost function can be specified as a set of data points, for example derived from

data sheets or single measurements. These data sets are used as lookup tables


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


and can provide precise results for a specific combination of input values.

Potentially, the system might be able to interpolate the values in the data set to

allow evaluation of parameter combinations that were not examined previously.

A cost function can be given as an analytical function that approximates the hard-

ware costs and may be derived from different implementations of a hardware

block.

9.4. Guidelines for application development

DESERVE deliverable D2.5.6 [12] describes application development guidelines. Common

guidelines for modules and functions concentrating on the co-design methodology for the

development of hardware dependent software functionalities as well as application

specific guidelines for the DESERVE demonstrators were defined and are described in this

document. Common guidelines for modules and function developments including

software framework tools, build process flow and suggestions for using software

framework tools are summarized in this section.

9.4.1. Co-design methodology

A first possible co-design platform consists of ADTF and the FPGA-based hardware

platform allowing the co-design of software and hardware for applications and algo-

rithms. The whole application or algorithm can be implemented in software using the

ADTF concept of filters. Single filters or the whole application can then be implemented in

hardware and linked to the ADTF environment. This allows reusability, flexibility and fast

verification of the implemented hardware modules.

Quantitative hardware cost models allow to evaluate different characteristics of the

hardware modules early in the development phase, e.g., based on parameters derived

from the software implementation. They may also provide hints to the software

developers that can guide the parameter selection process, in order to make efficient

hardware implementations possible.

There are of course further co-design platforms, which may be used in the development

process for other DESERVE demonstrators, e.g. RTMaps. Similarly, an FPGA is not the


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


only suitable hardware platform, there are other approved and similar systems too, e.g.

powerful multi-core microcontrollers, digital signal processors etc.

9.4.2. Deployment of hardware dependent software functionalities

Objective of the SW framework is to provide a unified platform for the software develop-

ment to demonstrate upcoming family of microcontrollers. Target users are the applica-

tion engineers and customers who use the application examples or demo software drivers

for prototyping. Target application domain is automotive.

The SW Framework has two main parts (Figure 46):

Software development tools

Software objects consisting of microcontroller application examples

The release of SW Framework consists of folders consisting of software development

tools and software objects consisting of template projects.

Figure 46: Software framework

SW Framework Tools Build Process Flow

Software components are input to the development tools to generate the output as

shown in Figure 47 below:


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


Figure 47: Software development tools

Framework tools are responsible for following activities:

Software components are scanned by the project scan process and the file list is

developed for next process.

Files listed in the file list are used for Indent to make standard code style for-

matting (GNU Indent is used in the SW Framework).

The Make file is generated using the file list and these make files are invoked

during the build process to generate the executables.

Doxygen tool runs on the files listed in the file list to generate project documents.

Motivation to use the SW Framework Tools

The framework tool environment is very helpful for demo software development because

of the following reasons. The SW Framework

provides the uniform structure for project files organization, API usage and tool

chain environment,

makes it easy to switch between different tool chains without changing source

code,

builds the make files automatically for the source files (it scans all the C, header

and assembly files inside the source folder and it generates the make files depen-

ding on the used tool chain),

provides the documentation possibility and


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


provides an easy structure to handle homogeneous and heterogeneous multicore

software.

9.4.3. Guidelines related to ISO26262

ISO 26262 is a derivative of IEC 61508, the generic functional safety standard for

electrical and electronic (E/E) systems. It is designed for series production cars, and

contains sections specific for management, concept and development phase, production,

operation, service and decommission. The DESERVE project focuses on the concept and

development (at system, hardware and software level) phases of the lifecycle (see

section 9.2). During these phases, the main steps defined by the Standard are:

Item definition: the Item has to be identified and described. To have a satisfactory

understanding of the item, it is necessary to know about its functionality, interfaces, and

any relevant environmental conditions.

Hazard analysis and risk assessment: to evaluate the risk associated with the item under

safety analysis, a risk assessment is required. The risk assessment considers the

functionality of the item and a relevant set of scenarios. This step produces the ASIL

(Automotive Safety Integrity Level) level and the top level safety requirements.

The ASIL is one of the key concepts in the ISO 26262. The intended functions of the

system are analyzed with respect to possible hazards. The ASIL asks the question: “If a

failure arises, what will happen to the driver and to associated road users?".

The risk of each hazardous event is evaluated on the basis of:

Frequency of the situation (or “exposure”)

Impact of possible damage (or “severity”)

Controllability

The ASIL level is standardized in the scale:

QM: quality management, no-risk

A, B, C, D: increasing risk with D being the most demanding.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


The ASIL shall be determined without taking into account the technologies used in the

system. It is purely based on the harm to the driver and to the other road users.

Identification of technical safety requirements: the top level safety requirements are

detailed and allocated to system components.

Identification of Software and Hardware safety requirements: The technical safety

requirements are divided into hardware and software safety requirements. The

specification of the software safety requirements considers constraints of the hardware

and the impact of these constraints on the software.

To take into account the functional safety approach, the DESERVE applications should

consider the application of the following main points:

1. Analyze risk early in the development process

2. Establish the appropriate safety requirements

3. Consider these requirements in software and hardware development

The impact of the standard is different for the development of warning functions, control

functions or automated driving functions.

10. Conclusions

The basic idea and intention of the DESERVE project is to standardize the interfaces

between the different development levels in the process of the development of next

generation, safety relevant ADAS systems as far as possible:

Development level 1: PC-based development framework

Development level 2: Rapid prototyping platform including software

superstructure (e.g. embedded PC / embedded controller with realtime operating

system and FPGA)

Development level 3: Fully embedded, AUTOSAR compatible architecture (e.g.

multicore controller with FPGA) for the evaluation of algorithms in realtime and


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


implementation of safety requirements according to ISO 26262 (e.g. pre-

certification for testing on public roads)

The development platforms of all stages can be used together with the model-based

design space exploration approach for system on chip and libraries of basic building

blocks for the FPGA. Being able to use already tested and validated building blocks and

software modules greatly facilitates and expedites the development process.

To support the model-based development of algorithms at all processing layers (percep-

tion, decision making, warning and control strategies), to verify and validate the

algorithms by virtual testing and finally to execute these algorithms in the vehicle, the

DESERVE platform level 3 needs to be fully compatible to the AUTOSAR standard. In

addition, at this development level, safety mechanisms need to be in place (according to

ASIL classification, ISO 26262) for vehicle road tests.

As a result, using the DESERVE platform concept, OEMs are able to define early and

precise enough the distinct requirements for the final ECU hard- and software (e.g.

required interfaces - which I/O and bus system; computational power; memory

requirements), including the safety mechanisms (e.g. memory protection, lockstep

operation). Further, the platform methodology and concept integrates safety features

and guarantees AUTOSAR compliance.

Based on the seamless support of all previously mentioned ADAS development levels the

flexible DESERVE platform concept summarized as a whole in this report helps to shorten

the iteration cycles (see Figure 3, page 15) in the system development significantly,

thereby boosting the development of next generation ADAS systems.


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


REFERENCES

[1]. International Organization for Standardization (ISO), ISO 26262, Road vehicles --

Functional safety, 2011.

[2]. DESERVE deliverable D1.2.1 – Development platform requirements

[3]. DESERVE deliverable D1.3.1 – Development platform specification

[4]. DESERVE deliverable D1.3.2 – Method and tools specifications

[5]. DESERVE deliverable D2.1.1 – Development system

[6]. DESERVE deliverable D2.1.2 – Development system

[7]. DESERVE deliverable D2.1.3 – Development method

[8]. DESERVE deliverable D2.1.4 – Development method

[9]. DESERVE deliverable D2.2.1 - Perception layer - Preliminary Release

[10]. DESERVE deliverable D2.5.2 – Platform system architecture

[11]. DESERVE deliverable D2.5.4 - Standard interfaces definition

[12]. DESERVE deliverable D2.5.6 - Guidelines for applications

[13]. DESERVE deliverable D2.6.1 – Virtual testing solutions analysis

[14]. DESERVE deliverable D6.1.2 – Validation Plan

[15]. TargetLink, www.dspace.com/en/pub/home/products/sw/pcgs.cfm

[16]. Embedded Coder, www.mathworks.com/products/embedded-coder/

[17]. AUTOSAR, http://www.autosar.org

[18]. EB Assist ADTF, http://automotive.elektrobit.com/driver-assistance/eb-assist-adtf

[19]. RTMaps, http://www.intempora.com/

[20]. ADASIS v2 Protocol, http://www.ertico.com/adasisforum

[21]. ADASIS v2 Horizon Reconstructor Blockset,

https://www.dspace.com/en/inc/home/products/sw/impsw/adasis_v2_hr_blockset.

cfm

[22]. Infineon Aurix Microcontroller,

http://www.infineon.com/cms/en/product/channel.html?channel=db3a30433727a4

4301372b2eefbb48d9

[23]. DESERVE deliverable D2.6.3 - Specification of a virtual test lab for DESERVE

development platform

http://www.dspace.com/en/pub/home/products/sw/pcgs.cfm

http://www.mathworks.com/products/embedded-coder/

http://www.autosar.org/

http://automotive.elektrobit.com/driver-assistance/eb-assist-adtf

http://www.intempora.com/

http://www.ertico.com/adasisforum

https://www.dspace.com/en/inc/home/products/sw/impsw/adasis_v2_hr_blockset.cfm

https://www.dspace.com/en/inc/home/products/sw/impsw/adasis_v2_hr_blockset.cfm

http://www.infineon.com/cms/en/product/channel.html?channel=db3a30433727a44301372b2eefbb48d9

http://www.infineon.com/cms/en/product/channel.html?channel=db3a30433727a44301372b2eefbb48d9


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


[24]. DESERVE deliverable D1.1.1 – Application database

[25]. DESERVE deliverable D1.1.2 – Platform needs

[26]. Association for Standardisation of Automation and Measuring Systems,

http://www.asam.net/

[27]. ASAM MCD-1 XCP, http://www.asam.net/nc/home/standards/standard-

detail.html?tx_rbwbmasamstandards_pi1%5BshowUid%5D=519

[28]. Arndt, O. J.; Becker, D.; Giesemann, F.; Payá Vayá, G.; Bartels, C.; Blume, H.

(2014): Performance Evaluation of the Intel Xeon Phi Manycore Architecture Using

Parallel Video-Based Driver Assistance Algorithms, Intl. Conf. Embedded Computer

Systems (SAMOS XIV)

[29]. ISO 26262, Road vehicles - Functional safety (www.iso.org)

[30]. Y. Papadopoulos, M. Walker, M.O. Reiser, M. Weber, D.J. Chen, M. Törngren, D.

Servat, A. Abele, F. Stappert, H. Lönn, L. Berntsson, R. Johansson, F. Tagliabo, S.

Torchiaro, A. Sandberg - Automatic Allocation of Safety Integrity Levels, 1st

Workshop on Critical Automotive Applications: Robustness & Safety, CARS 2010

(EDCC Workshop), Valencia, Spain, 27 April 2010

[31]. F. Tagliabo, S. Torchiaro, H. Lönn, R. Johansson, D.J. Chen, Y. Papadopoulos, M.

Walker, A. Sandberg - Modelling Support for the Automotive Functional Safety

Standard, IEEE Dependable Computing Systems (DEPCOS‘11), Brunow Palace,

Poland, June 27- July 1, 2011.

[32]. D.J. Chen, R. Johansson, H. Lönn, H. Blom, M. Walker, Y. Papadopoulos, S.

Torchiaro, F. Tagliabo, A. Sandberg - Integrated Safety and Architecture Modeling

for Automotive Embedded Systems, e&i - elektrotechnik und informationstechnik,

Volume 128, Number 6, Automotive Embedded Systems. Springer Verlag, 2011.

ISSN 0932-383X / 1613-7620

[33]. A. Sandberg, D.J. Chen, H. Lönn, R. Johansson, L. Feng, M. Törngren, S. Torchiaro,

R. Tavakoli-Kolagari, A. Abele - Model-based Safety Engineering of Interdependent

Functions in Automotive Vehicles Using EAST-ADL2, Lecture Notes in Computer

Science, Volume 6351, Series: Computer Safety, Reliability, and Security

(SAFECOMP), Pages 332-346. Springer Berlin / Heidelberg, 2011. ISSN 0302-9743

[34]. www.interactive-ip.eu


http://www.asam.net/nc/home/standards/standard-detail.html?tx_rbwbmasamstandards_pi1%5BshowUid%5D=519

http://www.asam.net/nc/home/standards/standard-detail.html?tx_rbwbmasamstandards_pi1%5BshowUid%5D=519

http://www.iso.org/

http://www.interactive-ip.eu/


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


[35]. www.haveit-eu.org

[36]. S. Durekovic (NAVTEQ), Perception Horizon: Approach to Accident Avoidance by

Active Intervention, Workshop “How can new sensor technologies impact next

generation safety systems?” IEEE IV 2011, June 5 2011, Baden – Baden

[37]. DESERVE Deliverable D2.2.1 – Perception layer Preliminary Release

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

[39]. ASAP2 file: http://www.asam.net/

[40]. AURIX Safety Manual, Infineon confidential document, no. AP32224, v1.1, dated

Sept. 2014

[41]. GNU indent documentation: http://www.gnu.org/software/indent/manual/

[42]. J. Rushby, "Modular Certification," NASA Contractor Report CR-2002-212130, NASA

Langley Research Center, 2002.

[43]. "Open Platform for EvolutioNary Certification of Safety-critical Systems," [Online].

Available: http://www.opencoss-project.eu/. [Accessed 19 09 2014].

[44]. "Road vehicles, Functional Safety Part 6: Product development at the software

level," in ISO/CD 26262, International Organization for Standardization (ISO),

2011, p. Part 10 – “Guidelines”.

[45]. "DO-297: Integrated Modular Avionics (IMA) Development Guidance and

Certification Considerations," Radio Technical Commission for Aeronautics (RTCA)

SC-200, 2005.

[46]. "Reliability of systems, equipment and components. Guide to the demonstration of

dependability requirements. The dependability case.," in IEC 62741/Ed1, 2013.

[47]. "Dependability of Software Products Containing Reusable Components – Guidance

for Functionality and Tests," in IEC/PAS 62814/Ed1, 2013.

[48]. J. Rushby, "Just-in-Time Certification," in 12th IEEE International Conference on

the Engineering of Complex Computer Systems (ICECCS), Auckland, New Zealand,

2007.

http://www.haveit-eu.org/


https://www.gnu.org/software/indent/manual/


SP2 – WP2.5 - D25.8


Contract N. 295364

09.04.2015


[49]. J. Rushby, "Runtime Certification," in Runtime Verification, 8th International

Workshop, Budapest, Hungary, 2008.

[50]. K. Östberg und M. Bengtsson, „Run time safety analysis for automotive systems in

an open and adaptive environment,“ in SAFECOMP 2013 - Workshop ASCoMS

(Architecting Safety in Collaborative Mobile Systems), Toulouse, France, 2013.

[51]. J. Frtunikj, M. Asmbruster und A. Knoll, „Data-Centric Middleware support for ASIL

assessment and decomposition in open automotive systems“.

[52]. "IEC 61508: Functional safety of electrical/electronic/programmable electronic

safety-related systems , Ed. 2.0," International Electrotechnical Commission, 2010.

[53]. D. Schneider und M. Trapp, „Engineering Conditional Safety Certificates for Open

Adaptive Systems,“ in In Proc. of the 4th IFAC Workshop on Dependable Control of

Discrete Systems (DCDS), pp. 139-144, York, 2013.

[54]. "OSGi Framework," OSGi Alliance, [Online]. Available: http://www.osgi.org.

[Accessed 28 11 2014].

deserve platform – 2nd release

Documents