deserve platform – 2nd release
Post on 08-Dec-2016
234 Views
Preview:
TRANSCRIPT
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 2
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 3
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 4
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 5
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 6
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 7
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 8
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 9
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 10
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 11
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 12
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 13
of 139 DESERVE Deliverable D25.8
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 ?
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 14
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 15
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 16
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 17
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 18
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 19
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 20
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 21
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 22
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 23
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 24
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 25
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 26
of 139 DESERVE Deliverable D25.8
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]).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 27
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 28
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 29
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 30
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 31
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 32
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 33
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 34
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 35
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 36
of 139 DESERVE Deliverable D25.8
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,
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 37
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 38
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 39
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 40
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 41
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 42
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 43
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 44
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 45
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 46
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 47
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 48
of 139 DESERVE Deliverable D25.8
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,
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 49
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 50
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 51
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 52
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 53
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 54
of 139 DESERVE Deliverable D25.8
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].
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 55
of 139 DESERVE Deliverable D25.8
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)
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 56
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 57
of 139 DESERVE Deliverable D25.8
Table 1: Application needs derived from the 33 considered DAS functions
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 58
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 59
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 60
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 61
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 62
of 139 DESERVE Deliverable D25.8
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,
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 63
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 64
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 65
of 139 DESERVE Deliverable D25.8
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-
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 66
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 67
of 139 DESERVE Deliverable D25.8
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,
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 68
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 69
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 70
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 71
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 72
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 73
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 74
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 75
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 76
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 77
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 78
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 79
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 80
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 81
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 82
of 139 DESERVE Deliverable D25.8
ID Type
Objective or Quantitative
Subjective
or Qualitative
Indicator Description Assessment criteria Development phases
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])
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 83
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 84
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 85
of 139 DESERVE Deliverable D25.8
Figure 24: Pieces of ADASIS specifications of the DESERVE platform perception
module
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 86
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 87
of 139 DESERVE Deliverable D25.8
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,
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 88
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 89
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 90
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 91
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 92
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 93
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 94
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 95
of 139 DESERVE Deliverable D25.8
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-
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 96
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 97
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 98
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 99
of 139 DESERVE Deliverable D25.8
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-
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 100
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 101
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 102
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 103
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 104
of 139 DESERVE Deliverable D25.8
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),
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 105
of 139 DESERVE Deliverable D25.8
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).
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 106
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 107
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 108
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 109
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 110
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 111
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 112
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 113
of 139 DESERVE Deliverable D25.8
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:
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 114
of 139 DESERVE Deliverable D25.8
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:
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 115
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 116
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 117
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 118
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 119
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 120
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 121
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 122
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 123
of 139 DESERVE Deliverable D25.8
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)
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 124
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 125
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 126
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 127
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 128
of 139 DESERVE Deliverable D25.8
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:
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 129
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 130
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 131
of 139 DESERVE Deliverable D25.8
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:
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 132
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 133
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 134
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 135
of 139 DESERVE Deliverable D25.8
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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 136
of 139 DESERVE Deliverable D25.8
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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 137
of 139 DESERVE Deliverable D25.8
[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
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 138
of 139 DESERVE Deliverable D25.8
[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.
DESERVE Platform – Final release
SP2 – WP2.5 - D25.8
PUBLIC Copyright DESERVE
Contract N. 295364
09.04.2015 Page 139
of 139 DESERVE Deliverable D25.8
[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].
top related