Download - HANSER automotive

© Carl Hanser Verlag, München www.hanser-automotive.de Nicht zur Verfügung im Intranet- und Internet-Angeboten sowie elektronischen Verteilern 

6 

electronics 

Microcontroller 

in Steering 

Sophisticated electronic control of the 

mechanics for Active Front Wheel and 

Rear-Wheel Steering 

systems 

27 

AUTOSAR 

“Our objective is a 

global standard”Interviev with 

Dr. Jürgen Mössinger, Vice 

President Automotive Systems 

Integration, Robert Bosch GmbH 

20 

Creating FlexRay COM 

Stack Configurations for ECUs 

in Complex Networks 

FlexRay Survey · Electronics FlexRay Microcontroller in Steering · FlexRay Applications Under 

Control · Creating FlexRay COM Stack Configurations for ECUs in Complex Networks 

AUTOSAR PDUs Conquer FlexRay · Development of AUTOSAR Software Components with 

Model-Based Design · Infotainment in an AUTOSAR environment

© Carl Hanser Verlag, München www.hanser-automotive.de Nicht zur Verfügung im Intranet- und Internet-Angeboten sowie elektronischen Verteilern


Measuring in Rough Environments – 

Sensor Close, Synchronous, and 

Accurate 

ES400 Measurement Modules 

Compact and rugged for sensor 

close installation, IP67 protection, 

extended temperature range 

-40...120 °C 

Powerful time-synchronous data 

acquisiton for accurate measurements 

of signals from different 

sources 

Integrated with all established development 

and measuring systems: 

INCA, CANape, PROVEtech:VA, 

MM6, DEWESoft 

ES400 modules cover all relevant 

applications: 

– ES410 – A/D Module 

– ES411 – A/D Module with 

Sensor Power Supply 

– ES420 – Thermo Module 

– ES430 – Lambda Module 

– ES441 – Counter and Frequency 

Module with Sensor 

Power Supply 

ETAS Group 

Whether you’re looking to 

shorten your development 

times or reduce your warranty 

costs – the ETAS Group 

has an answer. 

We supply a comprehensive 

portfolio of standardized 

development and diagnostic 

tools that cover the entire life 

cycle of electronic control 

units, from development to 

operational use and service. 

ETAS GmbH 

Borsigstraße 14 

70469 Stuttgart, Germany 

Phone +49 711 89661- 0 

Fax +49 711 89661-106 

sales.de@etas.com 

www.etas.com


ECU 

Calibration 

Experience with series projects. 

Choose proven FlexRay solutions. 

Take advantage of our extensive experience with FlexRay series 

projects. Use Vector’s comprehensive product portfolio for your 

FlexRay networking: 

> Simulate and test ECUs and networks with the sophisticated 

development environment CANoe and the FlexRay interfaces. 

> Profit from standardized ECU software. Vector software 

modules can be flexibly configured and easily integrated. 

> Ensure advantages in both quality and time: Rely on professional 

support during development and training. 

Get FlexRay on the road - with series-proven tools, scalable 

modules and 20 years of Vector networking know-how. 

Get on board: www.flexray-solutions.com 

Get the FlexRay Reference 

Chart now! 

www.flexray-solutions.com 

Vector Informatik GmbH 

Ingersheimer Str. 24 

70499 Stuttgart, Germany 

Tel. +49 (0) 7 11/80670-0 

www.vector-informatik.com


FLEXRAYl AUTOMOTIVE 2008l3 

FlexRay 

for passenger 

cars only? 

The next car to feature the fully equipped FlexRay 

network in series is on its way – the second time 

this technology has gone into series production in 

the automotive sector. Its capability is proven. This news, 

of course, also spreads to other industries: interest in 

FlexRay is growing. 

Dietmar Millinger 

Elektrobit Austria GmbH, 

A-1060 Wien 

The FlexRay consortium has invested a 

great deal in the technology for the automotive 

industry and has therefore done 

its bit. Every company in the consortium 

is entitled to do its own bit by equipping 

their own vehicles. But how shall the consortium 

benefit when third parties wish to 

use FlexRay? At the very least, it profits 

when FlexRay products and solutions are 

more widespread so they mature and 

improve. At the moment, using FlexRay is 

contractually defined for automotive applications 

only. Many interested parties from 

other industries, it is not clear what this 

precisely means. 

So, I will take a look on the Internet to 

find a definition for “automotive”. 

But, wait, SAE (http://www.sae.org/about/general/history/) 

already has a definition for “automotive”, maybe this provides 

some help . . . 

5 Minutes 

Should FlexRay be open to other 

industries? In our online survey we 

want to know, how you think about it. 

Join in for the questionnaire on 

www.hanser-automotive.de. 

The survey is completely anonymous 

and takes about five minutes.

© Carl Hanser Verlag, München A Uwww.hanser-automotive.de T O S A R Nicht zur Verfügung im Intranet- und Internet-Angeboten F L sowie E Xelektronischen R A Y Verteilern 

CONTENT 

4l SPECIAL EDITION FLEXRAYl AUTOMOTIVE 2008 

3 FlexRay, for passenger cars only? 

Preface from Dr. Dietmar Millinger, EB 

6 NEC Electronics FlexRay Microcontroller in 

Steering 

Dipl-Ing. Holger Schmerling, Dr. Costas Rente, Dipl-Ing. Sascha Galati 

Active (front wheel) Steering and Rear-Wheel Steering demands a 

very sophisticated control of torque and rotation of the actuator 

motors. Therefore the electronic Control of the Steering Mechanics 

with an Active Steering ECU and the Rear-Wheel Steering ECU 

10 dSpace: FlexRay Applications Under Control 

Dr. Ralf Stolpe, Dipl.-Ing. (FH) Björn Müller, Dipl. Inform. Joachim 

Stroop, Dipl.-Ing. André Rolfsmeier, Dipl.-Ing. (FH) Thorsten Hufnagel 

Combining FlexRay simulations with XCP on FlexRay 

16 Fujitsu: A Distributed Navigation Application 

enabled by FlexRay 

Fujitsu Microelectronics Europe and University of Applied Sciences 

Aschaffenburg (Prof. Dr.-Ing. J. Abke, Christian Eyrich,Matthias 

Steeg, Wolfgang Wiewesiek) Is FlexRay suitable for use in a navigation 

system? Can FlexRay be used to transfer moving image data 

between applications? A feasibility study has been undertaken to 

answer these questions in relation to a navigation application. 

20 TTTech Computertechnik AG: Creating FlexRay 

COM Stack Configurations for ECUs in Complex 

Networks 

Dipl.-Ing.Georg Stöger The allocation challenge of the FlexRay buffer 

memory. 

24 Vector Informatik and Audi AG: AUTOSAR PDUs 

Conquer FlexRay 

Dipl.-Ing. (FH) Wolfgang Brandstätter, Dr. rer. nat. Carsten Böke 

FlexRay Tools successfully support developments with PDU-based 

communications 

27 AUTOSAR: “Our objective is a global standard” 

Interview with Dr. Jürgen Mössinger, Vice President Automotive 

Systems Integration Robert Bosch GmbH, spokesperson of 

AUTOSAR until September 2008. 

29 The Mathworks: Development of AUTOSAR Software 

Components with Model-Based Design 

Guido Sandmann, Joachim Schlosser Top Down and Bottom up: 

From an architecture model to an AUTOSAR software component 

and reusing legacy models to generate AUTOSAR-compliant code 

31 OpenSynergy GmbH: Infotainment in an AUTO- 

SAR environment 

Dipl.-Ing. Frank-Peter Böhm, Dipl.-Ing. Rolf Morich, Dr. Stefaan Sonck 

Thiebaut AUTOSAR can be applied to typical vehicle functions, but it 

excludes precisely those areas which are most driven by the entertainment 

and telecommunications industries and in which customers 

experience innovations most directly and immediately. 

6 

Two ECUs directly affect the steering characteristics 

of the new BMW 7. A very 

sophisticated control of torque and rotation 

of the actuator motors requires a high 

precision closed loop control of the electrical 

BLDC motor. This is realized by a 

microcontroller that is able at the same 

time to frequently update information on 

motor currents and position, calculate and 

generate the corresponding PWM pattern 

required to drive the motor. 

This article describes the approach 

taken by a tool-based solution to compute 

and generate a buffer configuration 

and FlexRay Interface (FRIF) layer 

schedule that takes into account the 

limited resources of communication 

buffers and CPU time. 

29 

20 

Companies usually have an 

extensive library of mature and 

extensively tested models. It is 

important that these models 

can be reused to target different 

platforms such as AUTO- 

SAR without any changes to the 

models’ blocks.



6lA UTOMOTIVE 2008l SPECIAL EDITION FLEXRAY 

NEC FlexRay Microcontroller 

in Steering 

NEC Electronics anticipated the demand for high performance 

microcontrollers with embedded FlexRay for chassis applications 

and started the development of the V850E/PHO3 in 

2004. Consequently, the PHO3 was the world-wide first 

microcontroller with embedded FlexRay to successfully pass 

the FlexRay Conformance Test at TÜV Nord. 

One major highlight of the new BMW 7 Series car 

model is its innovative chassis combining comfort, 

driving pleasure and active safety. The so-called 

Integral Active Steering concept is a symbiosis of electro-hydraulic 

power steering controlling the steering force, 

Active Steering (AS) controlling the steering angle via an 

overriding drive and the optional Rear-Wheel Steering, 

Clearly a good coordination of these systems is needed to 

ensure an optimum steering behavior in all driving situations. 

This is done by the integrated chassis management 

(ICM) module and means the ICM needs to have close 

communication links to the actor systems. 

Actio - reactio: The dynamics of a chassis with its mechanically 

coupled components is determined by physics’ 

laws. Physics occur in real-time and do not care about bottlenecks 

such as bus protocols with limited bandwidth, high 

bus loads and unpredictable latencies. Therefore the need 

to control such a dynamic system via a network requires a 

high level of performance communication protocol. It is 

vital that it is able to keep pace with real-time requirements 

and cope with the amount of sensor data and actuator 

instructions.


The introduction of FlexRay as the 

new high performance automotive 

network protocol has paved the 

way for such an integrated chassis 

management system to efficiently 

control the interaction of distributed 

chassis functions (Fig. 1). 

Active Steering (AS) 

For the Active Steering a special 

gear is inserted into the column between 

the steering wheel and associated 

mechanics. Depending on the 

driving situation the impact of the 

steering wheel motion on the effective 

steering angle of the wheels can 

be changed by the AS. At slow city 

traffic (e.g at parking) the number of 

required steering wheel motions is 

reduced in order to make handling 

far more efficient. At higher speeds 

the steering behavior becomes 

more indirect, therefore the driver 

does not risk losing control of the 

vehicle as a result of unexpected 

and sudden steering wheel 

motions. 

Rear-Wheel Steering 

This is managed by means of a concentrically 

arranged brushless DC 

motor, which is positioned on the 

rear axle and moves the track rod 

through a spindle drive. The angle of 

the rear wheel can be controlled in 

a range of 3° maximum in both 

directions. 

For vehicle speeds of below 60 

km/h the rear wheels turn in the 

opposite direction of the front 

wheels thus enhancing the agility 

of the car. When driving at higher 

speeds the rear wheels steer in the 

same direction as the front wheels thus achieving a better 

balance of the side forces between front- and rear-wheels. 

This way the stability of the car improves e.g. for an evasive 

maneuver whilst driving on the motorway. 

Electronic Control of the Mechanics 

Both the Active Steering ECU and the Rear-Wheel Steering 

ECU directly affect the steering characteristics of the car. 

This demands a very sophisticated control of torque and 

rotation of the actuator motors. To achieve this a high precision 

closed loop control of the electrical BLDC motor is 

required. In order to facilitate this a microcontroller is 

necessary. This microcontroller is able at the same time to 

frequently update information on motor currents and position, 

calculate and generate the corresponding PWM pattern 

required to drive the motor. 

SPECIAL EDITION FLEXRAYl AUTOMOTIVE 2008l7 

Fig. 1: Integral Active Steering FlexRay network 

Fig. 2: Integral Active Steering ECU 

© automotive 


Typically the key components of such an ECU are as follows: 

- Main Microcontroller: For AS and Rear-Wheel Steering 

this is the NEC Electronics V850E/PHO3, responsible for 

the BLDC motor control, sensor evaluation, FlexRay communication 

and diagnosis. 

- Monitoring microcontroller: required for application monitoring. 

- Power MOSFETs to convert the logical PWM output signals 

into high currents are required to drive a powerful 

BLDC motor. 

- Sensor electronics for reading the position of the motor 

anchor and the individual phase currents. 

- FlexRay bus interface. 

- Power supplies.


All this had to be realized in a 

compact ECU (Fig. 2) that can 

operate within harsh environmental 

conditions. Some of the 

challenging factors are: limited 

mounting space, high ambient 

temperatures due to the power 

dissipation of the MOSFETS and 

strict EMC requirements. 

Also the software becomes a lot 

more complex than before and 

requires more memory and 

more calculation performance(e.g. 

for the Flexray protocol 

stack). 


The microcontroller - V850E/PHO3 

A microcontroller that is able to satisfy all the above mentioned 

requirements is a rare thing. Taking into consideration 

NEC’s very well known high level of quality and long 

expertise in the chassis field (e.g. several million microcontrollers 

sold for electrical power steering) it was decided 

to use NEC’s V850E/PHO3 for the Active Steering and 

Rear-Wheel Steering projects (Fig. 3). 

In a “nutshell” the PHO3 features a high level of calculation 

power, a huge memory (1 MB), the capability to control 

BLDC motor actuators, an interface to the FlexRay network, 

is able to support the extended automotive temperature 

range (A2 grade) plus excellent EMC performance. 

In addition an integrated floating point unit has been implemented 

as this is required to support today’s approach of 

model based algorithm development. 

Many chassis applications have similar requirements to 

those above , but require more or less performance, resp. 

more or less memory. To cover this, NEC have created a 

dedicated product line, named “P” Series. The “P” series 

offers strong solutions for low, mid and high-end chassis 

applications. 

Key parameters of the FlexRay Network 

The FlexRay network is the key component which facilitates 

the fast exchange of data. This makes it possible for the 

actuators to behave in a coordinated way and demonstrate 

optimized quick reactions to compliment the physics of 

driving. 

As the FlexRay protocol was designed to allow a high flexibility 

a huge amount of parameters have to be chosen. 

One key parameter is the cycle time. As the FlexRay configuration 

should be unchanged for all cars within the 7 

Series platform and also future car series, it was a very difficult 

task to find the optimum balance required between 

network throughput and network load. 

Initially it was felt beneficial to have a high frequency of 

messages. But this would mean that seldomly sent messages 

would waste the network capacity. Finally it was 

decided to use a 10 Mbit transfer rate and 5 ms cycle time 

within the static and dynamic segments over a single channel. 

Although a network based purely on a passive bus 

would be preferable from cost 

point of view, it was finally decided 

to use a combination between the 

passive bus and star coupler. This 

was chosen because too many 

FlexRay nodes connected to one 

cable would detoriate the signal 

quality and hence limit the achievable 

bandwidth and quality of the 

signal transmission. 

V850E/PHO3 with Flex- 

Ray is running - What is 

next? 

Fig. 3: NEC V850E/PHO3 microcontroller 

As a result of the successful introduction 

of FlexRay into the first 

series project, other OEMs are now following and will present 

cars with FlexRay over the next couple of years. This 

means that FlexRay has been established as the automotive 

high performance communication protocol and will 

become a standard interfaces within the automotive mass 

market. In order to support FlexRay for broader application 

areas the topology of the FlexRay network has to become 

much simpler. Also more flexible concepts are required 

e.g. synchronization. This is already on the way with the 

FlexRay protocol specification 3.0. 

The next big challenge for future chassis ECU’s will be cost 

reduction. High optimization potential still can be found in 

simplification of the functional safety concepts, by applying 

microcontrollers with enhanced functional safety support. 

This could help eliminating or at least simplifying components 

such as additional monitoring microcontrollers or 

supervision ASICs. But it could also dramatically reduce 

the efforts on the SW engineering side. 

Why not focus on the actual application SW and have the 

HW perform all of the diagnostics still being done in SW 

like memory tests, core self tests and plausibility check of 

safety-relevant calculation results? And why not reduce the 

efforts for functional safety validation and the assessment 

process in the same way? 

Wouldn’t it be a relief to present an “out-of-the-box” selfsafe 

microcontroller with proven safety integrity level rather 

than generating a new FMEA for each ECU variant, 

even though the same microcontroller is used? 

All this could be addressed by a generic functional safety 

concept for the microcontroller saving tremendous efforts to 

set up and validate a new functional safety concept for each 

and every product line. NEC Electronics has already started 

designing a new chassis microcontroller family, the Px4 

Series to meet these demands. It will be optimized for automotive 

applications targeting IEC 61508 SIL3 certification 

and will use a single microcontroller to cover the span between 

a high level of functional safety at minimal costs. NEC 

has established a close cooperation with TÜV SÜD to monitor 

and assess the development of Px4 from the early conceptual 

phase to the final implementation in silicon. 

V850E/Px4 will feature an integral safety concept based on 

two redundant CPU subsystems checking simultaneous 

each others’ operation.


It will be accomplished by additional hardware diagnostics 

addressing those failure modes that need to be addressed 

in diagnostic SW or even external hardware today. 

From a performance point of view V850E/Px4 will expand 

the existing “P” Series roadmap and will feature greater 

calculation power due to the new superscalar E2 CPU core, 

plus an enhanced peripheral set which is tailored to meet 

future chassis application requirements. A full feature list 

can be downloaded from Internet:www.eu.necel.com/ 

applications/automotive/040_flexray 

Though planned to be manufactured in a state-of-the-art 

90nm process, the V850E/Px4 will also use a proven-in-thefield 

predecessor device as starting point for the new 

design - V850E/PHO3. The realization of this first NEC 

microcontroller with embedded FlexRay interface would 

not have been possible without the extremely close collaboration 

of BMW and the excellent strong team spirit that 

prevailed between both parties. 

Finally NEC would like to take this opportunity to thank all 

of the involved people, particularly the project teams at the 

BMW Group – both for a successful introduction of this 

device to the market and also for the drive and inspiration 

to tackle challenging new automotive market requirements. 


Dipl-Ing. Holger Schmerling studied electrical 

engineering at the Cologne University of 

Applied Sciences specializing in communication 

systems. For the past 6 years he has 

worked as an application engineer on Flex- 

Ray, TTCAN and AUTOSAR in the NEC Electronics 

Automotive Business Unit in Düsseldorf. 

Dipl-Ing. Sascha Galati studied electrical engineering 

at the University of Wuppertal with focus 

on automation technology. He gained 4 years 

experience as application engineer for automotive 

microcontrollers before joining the NEC Automotive 

Business Unit in 2003. Now he is technical 

product responsible for automotive chassis 

microcontroller products. 

Dr. Costas Rente studied Physics at the 

RWTH Aachen University. In his promotion 

thesis he developed semiconductor detectors 

for high energy physics. Since 2000 he is 

with NEC Electronics and now active in the 

project management of chassis products for 

the automotive market.



COMBINING FLEXRAY SIMULATIONS WITH XCP ON FLEXRAY 

FlexRay Applications 

Under Control 

Following the first successful use of FlexRay in a production application, 

numerous further projects are presently approaching production level. The 

test functions necessary for verifying these systems are made available by 

test systems that have been successfully applied in many projects. Other 

FlexRay functions in addition to ones for network verification also came 

into operation. Along with FlexRay, the Universal Measurement and Calibration 

Protocol, XCP, is also gaining in importance. This paper describes 

the methods being used for FlexRay simulations and provides an XCP on 

FlexRay application example. 

Setting up a FlexRay Simulation 

In-vehicle networks are in a state of constant further 

development, particularly since the announcement of 

FlexRay in the year 2000. dSPACE GmbH was one of the 

companies that got involved in developing tools for Flex- 

Ray at an early stage, in response to the need for comprehensive 

means of testing the new bus system. Vehicles 

have now been going into series production with 

FlexRay for over a year, and further vehicles and applications 

are just one step away from being launched on 

the market. It is clear that FlexRay will continue to 

advance rapidly. 

As the number of applications grows, so do the requirements 

on the necessary test tools and infrastructures. Building 

on the experience gained from previous applications, 

these tools must be given further test execution functions. 

The dSPACE solution for testing FlexRay is based on 

various hardware platforms and the FlexRay Configuration 

Package. It already includes comprehensive test functions 

that were also used in the first production project. 

The dSPACE tool chain, with its real-time-capable simulation 

platforms and with MATLAB/Simulink modeling facilities, 

consists of several parts. The resulting workflow for 

configuring a test system is shown in Fig. 1. 

The dSPACE FlexRay Configuration Package is used to configure 

a dSPACE system as simulation or monitoring nodes 

in a FlexRay network. The nodes selected by the user are 

configured with the dSPACE FlexRay Configuration Tool 

according to a FIBEX communication matrix containing 

scheduling information for signals and frames. Various 

views help in managing the FlexRay configuration. The tool 

uses the configuration to generate communication code 

and parameters for the FlexRay controllers (called CHI 

code). The communication information is extracted and




transferred to MATLAB/Simulink, where the data is used 

as parameters for FlexRay communication blocks from the 

RTI FlexRay Configuration Blockset. Application-specific 

Simulink models can be created using the RTI FlexRay Configuration 

Blockset as a basis, with data provided by the 

configuration tool. The block attributes are filled with data 

generated by the dSPACE FlexRay Configuration Tool. The 

blockset contains additional blocks that can be used for 

task execution control, interrupt and error handling, status 

information, and controller reset. The hardware is connected 

via the FlexRay interface to the FlexRay bus, and from 

there to the FlexRay ECUs which are the units under test. 

The FlexRay Configuration Package is not 

only concerned with simple restbus 

simulation for mimicking the network 

behavior, but also allows target-oriented 

failure simulation by checking potential 

failure cases. For example, the package 

can be used to insert logical corruptions 

in FlexRay communication to allow a 

cyclic FlexRay frame to be switched in or 

out, CRC algorithms to be switched 

during run time, etc. 

In addition, it is also possible to have a failure 

insertion on the physical level by 

simulating broken wires, short circuits, 

etc., or to vary the termination resistance. 

This can be done with suitable failure 

insertion hardware for differential 

busses. 

The dSPACE FlexRay Configuration Tool 

can create several kinds of time-triggered 

tasks for the various scenarios. In addition 

to these test functions for FlexRay 

networks, the tool can also be used in 

connection with the RTI Bypass Blockset 

and the Universal Measurement and 

Calibration Protocol (XCP). XCP is the successor to the 

much-used CAN Calibration Protocol (CCP). The advantage 

of XCP is that it provides strict separation between the protocol 

and the transport level, and is therefore open for the 

implementation of FlexRay or even future bus systems. 

XCP on FlexRay is part of the XCP family standardized by 

ASAM. The XCP concept is based on the master/slave principle, 

with the electronic control unit (ECU) as the slave. 

XCP on FlexRay is already being used in numerous projects, 

especially where the CAN bus has been replaced by 

FlexRay. 

Task-Synchronous Bypassing via XCP 

on FlexRay 

Due to the complexity of modern electronic control units 

(ECUs) and the limited time available for the development 

of new ECU generations, the entire ECU software is developed 

from scratch in only very few cases. Instead the existing 

ECU code is adapted or extended. The external 

bypass method is an efficient approach in this context, allowing 

new algorithms to be developed on a rapid prototyping 

system while the original ECU executes all the functions 

that remain unchanged. The input and output variables 

of the bypass model are exchanged, and task execution 

on the ECU and the prototyping system is synchronized 

via existing ECU interfaces such as XCP on FlexRay. 

The external bypass approach gives the greatest flexibility 

possible during the design phase, since there are almost 

no resource constraints such as RAM, ROM, processor 

performance, or I/O channels. Real-time behavior is guaranteed 

even for complex bypass functions. In addition, the 

autoboot options of the prototyping systems allow the 

behavior of new functions to be validated in realistic scenarios, 

for example during test drives. 

Fig. 1: Workflow with dSPACE’s FlexRay solution. 


In this configuration example, the dSPACE MicroAutoBox 

is used as a real-time prototyping system. The bypass function 

is calculated synchronously to an ECU task. As soon 

as all the input data of the bypass model is available, an 

interrupt is triggered and the bypass task on the MicroAutoBox 

is executed. Alternatively, task execution on the two 

systems can be synchronized by means of the FlexRay 

message schedule. Execution of the bypass task is then 

purely time-driven (Fig. 2). 

Real-Time ECU Access via XCP on Flex- 

Ray 

For developing ECU functions by means of the external 

bypass approach, it is usually necessary to configure the 

bypass interface in the modeling environment and to change 

the input and output signals of the bypass model 

without ECU code modifications. The RTI Bypass Blockset 

provides a generic user interface for this purpose, with the 

same look and feel no matter what ECU interface is actually 

used for bypassing. 

The XCP on FlexRay option of the RTI Bypass Blockset is 

based on the dSPACE FlexRay Configuration Package. The

Can you buy electronics system 

know-how to save time and money? 


Yes 

With semiconductors, sensors and 

Intellectual Property, developed by Bosch 

Innovation from Bosch: Share the benefits of 40 years Bosch experience in development 

and manufacture of innovative electronic components for the automotive market. 

Our semiconductors, power semiconductors and sensors cover a wide range of 

automotive applications. Our IP modules make the integration of communication and 

general functions fast and easy. For additional information, please visit our website: 

www.bosch-semiconductors.com 

Visit our booth at: 

Convergence, Detroit: October 20-22, Booth #233 

electronica, Munich: November 11-14, Hall A6, Booth #340


14lA UTOMOTIVE 2007l 2008l SPECIAL EDITION FLEXRAY 

Fig. 2:Task synchronization for bypass scenarios via XCP on FlexRay. 

Fig. 3: Workflow for function bypassing via XCP on FlexRay 

configuration tool in the package allows users to assign the 

XCP master node and to select and configure the XCP slots 

of the FlexRay cycle necessary for bypassing, using the 

information in the ASAM MCD2 FBX (FIBEX) file. A Simulink 

library is generated according to the FlexRay configuration. 

After that, the bypass model can be implemented. 

The appropriate blocks from the RTI Bypass Blockset are 

used for selecting a suitable XCP slot and associating it 

with variables to be read from and written to the ECU. The 

set of variables available for selection is provided by the 

ECU description (ASAP2) file. In addition, the RTI Bypass 

Blockset provides configuration dialogs for creating further 

ECU variables that were not described in the ASAP2 file 

and that can be used for read and write access (Fig. 3). 

The synchronization of the ECU and the rapid prototyping 

system can be implemented with the help of the FlexRay 

Message Schedule or the RTI bypass interrupt mechanism. 


If the interrupt mechanism is used, the 

calculation of the bypass model is triggered 

as soon as all the input values are 

available as specified in the model. If 

the FlexRay Message Schedule is used, 

the calculation of the bypass model is 

time-driven regardless of the input 

values that were received up to that 

point. The RTI Bypass Blockset offers 

various mechanisms to ensure data 

consistency 

Apart from function development 

making use of the external bypass 

approach, also various hardware-in-theloop 

(HIL) test scenarios require realtime 

access to ECUs. In these cases, 

the RTI Bypass Blockset can also be 

used on the HIL platforms: for example, 

for real-time tests or to capture the ECU 

data for real-time plausibility tests. 


Measurement and Calibration via XCP 

on FlexRay 

Adapting the ECU software to engine and vehicle variants 

and validating the vehicle behavior are important milestones 

during the ECU development process. These specific 

applications are supported by CalDesk, the universal measurement, 

calibration and diagnostic tool from dSPACE. For 

communication with ECUs via XCP on FlexRay, CalDesk 

provides an XCP master implementation that allows users 

to measure ECU-internal variables and to adjust calibration 

parameters in the ECU software via FlexRay. CalDesk also 

lets users record and analyze measurement data from the 

vehicle bus, external measurement modules, further ECUs 

and dSPACE real-time systems. It is also possible to simultaneously 

adjust parameters on different platforms. In addition, 

typical diagnostic tasks such as reading and resetting 

the ECU’s fault memory via dedicated instruments are sup-


FLEXRAYl AUTOMOTIVE 2008l 15 

ported. Measurement, calibration and diagnostic tasks can 

be remote-controlled via an ASAM MCD3-compliant 

COM/DCOM interface: for example, via MATLAB or AutomationDesk 

for ECU tests. 

Summary 

The examples in the previous sections show some basic 

concepts for the efficient simulation of FlexRay networks 

for ECU tests. The described methods are already being 

used in many customer projects and are based on dSPA- 

CE’s proven hardware and software simulation solutions. 

The capabilities and possibilities of dSPACE’s comprehensive 

tool portfolio were explained using an example of 

bypassing via XCP on FlexRay. In addition, the paper described 

the interaction of the FlexRay configuration tool with 

the RTI blocks, as well as with the experiment environments 

and tools for test automation. 

This high level of performance in customer projects is already 

assisting developers as they handle their test, measurement 

and calibration tasks in FlexRay projects. 

Dr. Ralf Stolpe has been working at dSPACE 

GmbH since 2000, and is responsible for projects 

pertaining to the development of Flex- 

Ray tools. 

Dipl.-Ing. (FH) Björn Müller has been a product 

engineer in the Hardware-in-the-Loop 

Simulator Team since 2006, where he is 

responsible for the bus system products of 

dSPACE GmbH. 

Dipl. Inform. Joachim Stroop is the Lead 

Product Manager for System and Function 

Design Tools at dSPACE GmbH. 

Dipl.-Ing. André Rolfsmeier is Senior Product 

Manager for ECU Calibration and Bypassing 

at dSPACE GmbH and, as such, is 

responsible for measurement and calibration 

interfaces in the dSPACE tool portfolio. 

Dipl.-Ing. (FH) Thorsten Hufnagel is Project 

Leader for ECU Interface and Bypassing 

systems at dSPACE GmbH. 

Right away – 

with FlexRay! 

DTS and EDICflex – 

the perfect solution for diagnostics and 

flash programming of FlexRay ECUs 

No matter whether in development, validation 

or production – EDICflex hardware interfaces 

allow reliable ECU communication at any time. 

The Embedded Diagnostic Module guarantees 

robust realtime behaviour in diagnostic and 

flash programming applications. 

Benefit from DTS solutions also in your 

applications – flexible user interfaces and 

automation APIs are ready for you. 

Contact us now! 

Tel.: +49 (89) 456 56 420, www.softing.com



Creating FlexRay COM Stack 

Configurations 

A FlexRay controller typically offers, or addresses via DMA access, several 

kilobytes of buffer memory. AUTOSAR defines a comprehensive set of layers 

to manage FlexRay communication in an ECU, from high-level signal 

management in the COM and handling of large data packets in the Transport 

Protocol layer down to the FlexRay Interface Layer for management of 

real-time interfaces and the hardware abstraction in the FlexRay Driver 

layer. But how can we efficiently allocate the FlexRay buffer memory of an 

ECU to the communication frames transmitted and received by an ECU? 

How does this affect the CPU load of this ECU, considering that each access 

to a communication buffer creates some work for the CPU? 

The Allocation Challenge 

The challenge itself is illustrated by an example: Assume 

a “telephone service” shop where 10 telephone 

booths are available for customer use and we are 

responsible for assigning customers to phones. Customers 

can “transmit” by making phone calls there, or 

“receive” by taking incoming calls there. How can we 

ensure that the use of the booths is optimized? 

Since we know our customers, we try to plan ahead: We 

have to exclusively reserve a booth for each of our “very 

important” customers. Whenever they require a phone, 

for ECUs in Complex 

Networks 

we need to have a phone booth available for them. Some 

customers are known for their short phone calls, usually no 

more than a few minutes. With regard to this additional 

information or “constraints”, we are able to develop efficient 

strategies for allocating phones to the customers. 

This illustrates the challenge that needs to be solved for 

complex real-time networks: We have a limited number of 

buffers (phone booths) and a large number of communication 

frames (customers), transmitted or received by the 

FlexRay communication controller (the shop) of our ECU. 

The buffers have to be allocated to the frames in a way so


that no information is lost (this happens if no buffer is free 

upon reception) or unduly delayed (this happens if no buffer 

is available when a transmission has to be made). 

Optimization Goal of AUTOSAR 

An additional constraint is related to how AUTOSAR handles 

the FlexRay communication: The interface handling the 

access to the FlexRay buffers, called the FlexRay Interface 

Layer (FrIf), is a software layer executed at certain pre-defined 

times and with certain pre-defined actions (“jobs”) 

such as packing and unpacking data. It is like the manager 

at the phone booth shop: he has some 

overhead getting up to assign a customer 

to a booth. If there are many booths 

and many customers, it would be more 

efficient to do several assignments in 

one step. These actions correspond to 

task activation in an ECU. If the FrIf has 

to be activated for each job (e.g. transmission 

or reception of a PDU), a lot of 

CPU time will be spent just on FrIf activations. 

It reduces the overhead significantly 

if we can group these jobs. 

A FlexRay communication controller 

offers dozens or hundreds of buffers, 

depending on the hardware and, in some 

cases, on the length of the messages. 

But several dozens or several hundred 

FlexRay frames may have to be transmitted 

and received on this node. This is not 

a fictional scenario: Some ECUs such as gateways need to 

send or receive many of the frames on a network, and a nontrivial 

FlexRay system will usually contain hundreds of different 

frames. For many of these frames (“static frames”), the 

frequency, phase and order are exactly known from the Flex- 

Ray communication schedule, while for others (“dynamic 

frames”), this is not necessarily so. 

Even with a copious amount of communication buffers, the 

authors found that it is not a trivial task to find proper allocations 

for the buffers when implementing AUTOSAR configurations 

for ECUs sending and receiving significant 


amounts of data in large FlexRay networks. As explained 

above, the challenge is to define the buffer allocation in a 

way that buffers are efficiently used, all frames can be 

received and transmitted in time, and the CPU load generated 

by the FlexRay Interface layer activations is kept to a 

reasonable minimum. 

Fig.1:The validity span of the buffers, shown for a period of the green and 

the blue PDU. When using 2 buffers for the frames in slot 2, there are just 4 

FRIF interrupts necessary. 


Several Possibilities for Allocation 

The purpose of the buffer allocation is to assign message 

buffers to slots and channels, select the buffer direction 

(“transmit” or “receive”), and define cycle counter filtering: 

Like for CAN, a FlexRay communication buffer can be 

programmed to receive only frames with defined identifiers 

or identifier ranges, e.g. “receive frame ID 3” or 

“receive frame IDs in the range 0x10..0x1F”. FlexRay communication 

is organized in (strictly) 64 communication 

cycles, and the filtering can refer to these cycles too, e.g. 

“receive frame 3 in any communication cycle” or, alternatively, 

“receive frame 3 only in communication cycle 20”. 

To find a buffer for every frame sent or received by a node 

can be a rather simple task when support for the FlexRay 

Interface layer is not considered: In this case, one buffer 

Mobile drives Automotive. 

Today‘s consumers are digital natives who live their life connected 

via blogs, communities, and online games. They expect anything, 

anywhere, anytime, on any device. 

Get mobile in your car. www.tietoenator.com 

TietoEnator is a professional service company providing IT, R&D 

and consulting services.



Fig. 2: A valid whitelist has to be within the validity span of a buffer. 

can be assigned to each slot, independent of the frame 

received in that slot. The buffer then needs to be read in 

each communication cycle, and the number of buffers is an 

upper limit for the number of nodes in a communication 

cluster, because a buffer is not allowed to be assigned to 

more than one slot. This relaxes constraints quite a bit: we 

may have hundreds of frames, but only dozens of slots and 

the number of buffers typically is sufficient for this strategy. 

But is it always possible? 

Validity Spans and Grouping of FrIf Jobs 

The following example illustrates how the buffer allocation 

can support the optimal FlexRay Interface layer configuration 

with respect to CPU load. For demonstration we choose 

a single-channel FlexRay network schedule with 8 

cycles (instead of the full 64) and 8 static slots (instead of 

the several dozens that large FlexRay schedules have). As 

shown in the figure 1, there are 2 PDUs sent in this slot – 

the first one (green) is sent every odd cycle and the other 

one (blue) is sent every even cycle. Initially, all frames of 

one static slot for transmission (or reception) could share 

one buffer. The disadvantage with this approach is that one 

FlexRay Interface interrupt has to be raised in every communication 

cycle to copy the PDUs from the system 

memory into the controller buffers for transmission (or the 

other way round, for reception). 

If the real-time constraints for the PDUs allow, one FlexRay 

Interface interrupt per two cycles would be sufficient. For 

this, two buffers have to be used, and FlexRay controller 

configuration specifies when (i.e. in which slot and cycle) 

which buffer is to be sent. Such a “cycle filtering” configuration 

is specified by a “base cycle” parameter (the first 

transmission will occur in cycle N of the 64 cycles) and a 

“cycle repetition” parameter (the transmission will reoccur 

every N cycles throughout the 64 cycles) for each 

buffer. One FlexRay Interface job can now be executed in 

the beginning of every odd cycle, copying both PDUs to the 

corresponding buffers. 

In this example configuration, the “validity span” of each 

of these two buffers is “two cycles”: Each buffer can be 

updated in a time interval lasting two cycles, before the 

transmission is performed by the FlexRay controller, and 

new data needs to be provided. It is easier to compute a 

schedule for the jobs of a FrIf to operate on buffers with 

large validity spans, just as it is easier for humans to enter 

a slow-moving merry-go-round than a fast-moving one. And 

larger validity spans usually mean that more FrIf jobs can 

be grouped together, resulting in lower CPU usage for FrIf 

activations/context switches. 

Application Constraints and Automatic 

Scheduling 

A more sophisticated buffer allocation algorithm is required 

when the application has additional timing constraints 

about “when does the communication have to take place”. 

We assume a communication schedule where several relevant 

PDUs are transmitted in a single slot (X). As shown in 

figure 2, 

 

 

 


PDU_A is transmitted with base cycle 0 and cycle 

repetition 4, 

PDU_B is transmitted with base cycle 0 and cycle 

repetition 1, 

PDU_C is transmitted with base cycle 1 and repetition 

2. 

Therefore, each frame in slot X contains 2 PDUs (in one 

case, one PDU is missing; this is “currently unused” frame 

space that can be used for later extensions to the schedule). 

In cycle 0 (with repetition 4), the frame contains PDUs 

A and B, in cycle 1 (with repetition 2!) the frame contains 

PDUs B and C, and in cycle 2 (with repetition 4), the frame 

contains just PDU B. Assuming an application is concerned 

with data in PDU_A and PDU_C, FlexRay data for this application 

will be received in 3 out of every 4 cycles. However, 

let’s say the application requires – here is the additional 

constraint (in complex systems there will be several of 

these) – that the AUTOSAR COM functions are only executed 

at the end of every second communication cycle. 

(Such a constraint is typically defined to ensure that legacy 

applications are not interrupted by basic software activations). 

Allocating one buffer for slot X is now forbidden, 

because we get new data in three out of four cycles, but 

we are not allowed to schedule one FlexRay Interface activation 

per cycle. Hence a smart buffer allocation algorithm 

is necessary to maximize the validity span of buffers: two


buffers are used for slot X! BUFFER_A holds the frame with 

PDUs A and B (validity span: 4 cycles), and BUFFER_B 

holds the frame with PDUs B and C (validity span: 2 cycles). 

Now the FlexRay Interface activations can be successfully 

placed in an interval labeled “whitelist” in figure 2. Whitelists 

are used-definable intervals of time in the cycle, specifying 

when a PDU may be handled by the FrIf. Whitelists 

are often used to formulate application constraints for FrIf 

activities, in this case “process the PDUs only every 

second cycle”. 

In this example, no cycle filter mask can be defined which 

contains PDU_A and PDU_C and still meets the application 

constraint. Using several buffers for one slot, and configuring 

each of these buffers with appropriate cycle filtering, 

may be required to meet all constraints encountered in a 

typical AUTOSAR FlexRay ECU. 

Available Tool Support 

The combination of 

hardware constraints – how many buffers (and sometimes: 

which with restrictions regarding filtering) are 

available? 

network schedule constraints – when is which PDU 

available for reception/when does it have to be provided 

for transmission? 

application constraints – when, for whatever reason, 

shall the FrIf perform its FlexRay handling jobs for specific 

PDUs (whitelists) and when is it forbidden to execute 

any such jobs (blacklists)? Are there any buffers 

that must not be used because they are reserved for 

something else (e.g. a FIFO)? 

the goal for optimization – group FrIf activities as 

much as possible to reduce the CPU load from activations/context 

switches 

is managed by a scheduling algorithm that automatically 

computes at which times during each cycle which FrIf jobs 

have to be executed to fulfill all of these constraints. The 

tool performing this scheduling algorithm is called TTX- 

Build. In order to generate a FrIf schedule for an ECU, the 

TTX-Build FrIf scheduler gets as input 

 

 

 

 

the (often hundreds of) PDUs and frames on the Flex- 

Ray network (FIBEX file), 

the hardware definition of the FlexRay controller of 

the node (ECU definition), 

the specification which of the PDUs are to be sent or 

received by this ECU (node configuration), e.g. for 

AUTOSAR COM (signal based communication interface), 

NM (network management) or TP (transport 

protocol), 

application constraints in the form of time intervals for 

“do” and “don’t” execute FrIf actions (blacklists and 

whitelists). 

The resulting FrIf schedule contains as few as possible (to 

minimize the CPU overhead) but as many as necessary FrIf 

“tasks”, i.e. definitions of which activities the FrIf has to execute 

at certain points in time (referring to the FlexRay network 

time). 

FLEXRAYl AUTOMOTIVE 2008l 23 

A tool for generating and checking specific parts of ECU 

software and configuration data needs to support integration 

in a development tool chain, where it can be used either 

for manual (GUI) or automatic (batch mode) operation. 

In the FlexRay ecosystem, this means compatibility to welldefined 

input and output file formats to support the workflow 

and development processes suggested by AUTOSAR 

and established automotive electronics development processes. 

In case of TTXBuild, it reads the FlexRay cluster 

description and network schedule from a FIBEX (Field Bus 

Exchange Format) file, takes node configuration data from 

a GUI or a user-supplied database (including scripting support 

for automatic generation of such a database) and generates 

the configuration XML files as described in AUTO- 

SAR. 

Dipl.-Ing.Georg Stöger studied Realtime 

systems at TU Wien. Since 1998 he is working 

for TTTech Computertechnik AG, Vienna, 

Austria. Today, he is leading the Core Technology 

Unit. 

FlexConfig - design and 

configuration software 

for FlexRay. 

By Eberspächer Electronics. 

Comfortable graphical editors and wizards 

Lossless import, export and editing of FIBEX 

(1.2.0a, 2.0.0d, 2.0.1 and 3.0.0) 

Converter for FIBEX+ to FIBEX 3.0.0, 

FIBEX 2.0.1 to FIBEX 3.0.0, CANdb to 

FIBEX 2.0.1/3.0.0 

Support of PDUs 

CHI-exports for all major 

communication chips 

www.eberspaecher.com



FLEXRAY TOOLS 

SUCCESSFULLY SUPPORT 

DEVELOPMENTS WITH PDU- 

BASED COMMUNICATIONS 

AUTOSAR PDUs 

Conquer FlexRay 

Audi is using FlexRay in their newest vehicles. The developed Flex- 

Ray network communication uses PDUs (Protocol Data Units) that 

are fully AUTOSAR compatible. PDUs are logical data containers 

for exchanging signals between applications and allowing greater 

decoupling from the underlying communication system. Audi benefited 

immediately from Vector’s CANoe as a bus analysis and simulation 

tool which can natively handle PDUs. 

With the release of the frame-oriented FIBEX 

2.x database format, a new description semantic 

was needed to define PDU communications 

between network nodes. To overcome this gap, 

Audi successfully developed the FIBEX+ description 

semantic. Vector was able to immediately support 

FIBEX+ in its tools. Profiting from their experiences with 

FIBEX+, Audi introduced PDUs into the new FIBEX 3.0 

standard from ASAM (Association for Standardisation of 

Automation and Measuring Systems [1]). 

Continuous feedback from Audi enabled Vector engineers to 

integrate important PDU features during the early phases of 

tool development. Service Packs were delivered regularly to 

Audi, thus, allowing early testing of ECUs with PDU communication 

stacks. Audi delivered their latest FIBEX+ database 

versions to Vector in order to ensure CANoe’s continuous 

compatibility. Close collaboration between Audi and Vector 

accelerated the tool development and led to a professional 

analysis and development platform for FIBEX+ and the 

new FIBEX 3.0 based FlexRay networks. 

This article illustrates the impact PDUs have on the internal 

structure and features of a FlexRay development tool 

CANoe.FlexRay and how Audi engineers benefit from 

appropriate tool support.


PDU Layer for Network 

Analysis 

PDUs are managed by tools for analysis, 

simulation, and test as high-level communication 

data containers (e.g. messages) 

containing signals. A FlexRay frame can 

contain several PDUs. Since the layout of 

a frame can also change from cycle to 

cycle, the same PDU can be mapped to 

multiple frames. PDUs are uniquely identifiable 

by their position in a FlexRay frame 

in a specific slot during a specific cycle. 

Vector identifies PDUs in CANoe via the 

PDU Layer (Figure 1). The PDU Layer 

introduces PDU objects and is located 

between the bus and the user interfaces, 

respectively. The layer is enabled or disabled 

according to the assignment of an 

appropriate database (FIBEX+ or FIBEX 

3.0) to CANoe. If the layer is enabled, then 

the complete symbolic database interpretation 

(PDU names, signals, timings, etc.) 

of the network communication is performed 

at PDU level. 

The PDU’s main property, which is defined 

by the Update Bit, is decoupled from 

the frame’s occurrence on the network. 

Thus, frames on the network may contain 

updated and non-updated PDUs at the 

same time. Update Bit values can be visualized 

as pre-defined signals or can be 

evaluated (e.g. in the graphics window, 

see Figure 2). As a default for simple analysis 

or simulation received PDUs, which 

have not been updated, are ignored. For a 

detailed analysis, however, non-updated 

PDUs can optionally be displayed and passed 

on to the simulated nodes. In addition, 

FlexRay frames including their payload 

can be displayed and received as socalled 

Raw Frames. Such PDU-based analysis 

features were heavily used by Audi 

during their integration tests. 

PDU Layer for Network 

Simulation 

Although the FlexRay protocol defines frames to be transmitted 

cyclically (even without any update), native PDUs do 

not have this property. If a PDU is not updated, the receiver 

will normally not recognize the PDU. In order to trigger 

the receiver cyclically, PDUs must be updated periodically. 

If the automatic transmission of PDUs with the Update Bit 

set (i.e. without any explicit data update) is required, then 

the network designer can define these PDUs to have cyclic 

timings. For this reason an Interaction Layer (see Figure 3) 

on top of the PDU Layer was developed to handle those 

constraints. As an extension to the FlexRay protocol, PDUs 

may also be sent cyclically with (nearly) arbitrary periods 

with set Update Bit (without being updated). 


Figure 1: CANoe’s Architecture with Abstraction Layers for Signal and PDU Handling 

and Sending Behaviour (IL). 


Figure 2: CANoe’s visualization of PDU’s Update Bits in Graphics and Trace. 


Message counters and check sums were defined by Audi 

as additional but optional validity attributes of a PDU. In 

fact, the Update Bits, message counters, and check sums 

of a PDU are set independently from the application in 

CANoe by the Interaction Layer in order to simplify the 

remaining bus simulation. Thus, the engineer can concentrate 

on setting appropriate signal values. A further use 

case is the insertion of explicit failures into the remaining 

bus simulation in order to test an ECU’s reaction. Therefore 

every automatic feature in CANoe can be disabled and 

the Interaction Layer can be used for fault injection. 

A simulation of communications with an ECU depends on 

the occurrence of specific events (event-based simulation).



Figure 3:The Interaction Layer (IL) of CANoe controls the sending behaviour of PDUs with set Update Bit inclusively 

their extended validity attributes (message counter, user CRC). 

One of the most important events is the reception of messages 

or changes in signal values from the bus. As such, 

notification handlers for PDU reception and signal changes 

are triggered by the PDU Layer. 

Performance Aspects 

The additional (but mandatory) PDU Layer does create 

some overhead. When receiving FlexRay frames, PDUs 

have to be extracted from the frame and then forwarded 

to their notification handlers in the application. The same 

PDU can be contained in different frames. Thus, a sort of 

de-multiplexing of PDUs from frames is implemented by 

the PDU Layer. These procedures are highly optimized. 

On transmitting PDUs, they must be stored in the appropriate 

frame. The PDU can be located in different frames 

according to the current (cycle) time or a different set of 

PDUs may be contained in the frame. This results in a highly 

time-dependent multiplexed mapping of PDUs to Flex- 

Ray frames. If this is not fast enough, then frame slot misses 

should be expected. For maximum performance, Vector 

has implemented those functions to run on the hardware 

for the FlexRay bus interfaces of the VN series. 

Testing PDU-based Networks 

Audi and its Tier1 suppliers also benefited from CANoe’s 

AUTOSAR features. This includes a check for communication 

conformance in order to test the AUTOSAR communication 

stacks (especially the PDU Router) of the ECUs. 

Here it is of great importance to be able to compare the 

real bus entities (Raw Frames) with the symbolic interpretation 

(PDU abstraction level). 

Drehzahl erfassen und 

zuverlässig überwachen 

Vom Geber bis zu jeder Auswertung: 

Lösungen aus einer Hand! 

BRAUN GMBH 

DREHZAHL UND FREQUENZ 

D-71301 Waiblingen · Tel: 07151 / 9562- 30 

Fax: 07151 / 9562-50 · info@braun-tacho.de 

www.braun-tacho.de 

This helped the Audi engineers 

to identify in early phases 

an incorrect PDU or Update 

Bit position in the raw Flex- 

Ray frames. 

Tests can be split into two 

categories: First the application’s 

transmission behaviour 

can be checked with respect 

to updated PDUs and secondly, 

a signal’s integrity can be 

verified according to the application. Audi‘s engineers have 

successfully detected incorrect PDU update timings in 

early development phases. These tests are fully supported 

in CANoe’s Test Feature Set for PDUs. Additionally, for stimulus 

and response observations, PDUs can be sent interactively 

(PDU Panel) by implicitly manipulating signals 

(Input Panels), higher level protocols (transport, diagnostics), 

or by a remaining bus simulation (CAPL, MATLAB 

models, etc.). 

Conclusion 

PDU-based communications will not only be used in migration 

scenarios, e.g. when porting applications from CAN to 

FlexRay networks, but also for new FlexRay developments. 

Audi has strongly influenced the development of 

FIBEX 3.0 based on lessons learned with FIBEX+. Vector’s 

experience with FIBEX+ allowed the quick support of the 

new FIBEX 3.0 standard with CANoe. As communications 

become more complex and extensive, appropriate modelling 

standards (i.e. FIBEX 3.0 and/or AUTOSAR), as well as 

their professional tool support, are essential requirements 

for an efficient FlexRay development. 

Literature: 

[1] www.asam.org 


Dipl.-Ing. (FH) Wolfgang Brandstätter 

is Hardware and Protocol Engineer for 

FlexRay; 

AUDI AG, 85045 Ingolstadt, Germany 

Dr. rer. nat. Carsten Böke is Senior Software 

Development Engineer for the “Tools for Networks 

and Distributed Systems” product line; 

Vector Informatik GmbH, 70499 Stuttgart, 

Germany


LOOKING BACK ON NINE MONTHS OF 

FORGING THE INITIATIVES GOALS, 

DR. MÖSSINGER TALKS ABOUT 

ACHIEVMENTS AND CHALLENGES. 

“Our objective is a 

global standard” 

Since the beginning of this year, Dr. Jürgen 

Mössinger was spokesperson of the AUTO- 

SAR development partnership. The objective 

of this initiative is to manage the complexity 

of software development by standardization 

of basic system functions, scalability and 

transferability of functions with consideration 

of safety requirements. This results in a 

better maintainability, exchangeability and 

reuse of software components, easier software 

updates and provides a basis for the 

use of „Commercail off the shelf“ hardware. 

Dr. Mössinger, how has AUTOSAR developed during 

the last year? 

AUTOSAR began Phase 2 in early 2007. In launching 

release 3.0, which was released in late 2007 and published 

in February 2008, the consortium has created a stable 

basis for the automotive industry. This includes the complete 

system software, along with the methodology and, 

for the first time, also Application Interfaces. On this basis, 

vehicles will go into series production on a wide scale. In 

August 2008, we concluded the specifications for on-board 

diagnostics. OBD is prescribed by law in many countries 

and the support for this standard consequently represents 

a significant step toward the internationalization of AUTO- 

SAR. A subject particularly dear to my own heart. 

When can we expect to see products on the road? 

Very soon. By 2010, all nine core partners will have 

launched AUTOSAR-compliant control units onto the 

market. 

Have you also received inquiries from other industries? 

People are generally interested and, we have naturally also 

received inquiries, as has been the case for FlexRay. The 

focus at the moment, however, is exclusively on the automotive 

industry. 

SPECIAL EDITION AUTOSARl AUTOMOTIVE 2008l27 

Dr. Jürgen Mössinger, Vice President Automotive 

Systems Integration Robert Bosch 

GmbH. He was spokesperson of AUTOSAR 

until end of September 2008. 

The process of internationalization you are forging 

ahead with makes AUTOSAR itself more complex. Isn’t 

it more of a hindrance, to have to take requests from 

other companies into account? 

Experience teaches us that local standards are not the 

route to success and would only lead to a further fragmentation 

of the subject. We have adopted a global standard 

as our objective. In this respect, the consortium offers 

various levels of membership. Thanks to internationalization, 

the number of members is rising and thus also the 

number of companies working with us on the further development 

of the standard. 

Japan showed interest in AUTOSAR and FlexRay at an 

early stage. Have things gotten any closer there? 

Japan has a strong automotive industry. There are two barriers, 

however, that impede the flow of information: on the 

one hand, the distance, and on the other, the complex 

Japanese language. 

By increasing the AUTOSAR presence at conferences and 

conventions, we have now succeeded in integrating Asia 

and in particular Japan to a greater extent. By way of illustration, 

the connection to Jaspar has now also been defined. 

JASPAR incorporates the “AUTOSAR/Flexray Standardization” 

working group, which performs a bridge function


28lA UTOMOTIVE 2008l SPECIAL EDITION AUTOSAR 

between AUTOSAR and JASPAR. This working group is led 

by Bosch/Japan. AUTOSAR and JASPAR both aspire to one 

global standard. 

How do things look in the other direction – North America? 

The activities in the U.S., and the efforts on the part of the 

member firms there, are increasing. October saw us organize 

a local AUTOSAR conference for the first time, which 

directly followed up the Convergence conference in Detroit 

and attracted a great deal of interest. 

By nature, people in the U.S. are skeptical about European 

developments. How do you rate AUTOSAR’s 

chances? 

Basically speaking, AUTOSAR chances are good. The standard 

is merely being introduced with a slight time lag, adapted 

to the introduction of corresponding new platforms. 

Here, too, safety issues, the CO2 debate and stricter 

exhaust emission regulations are also the driving forces 

behind electronics and for increasing levels of software. At 

convergence 2008 the Big Three GM, Ford und Chrysler confirmed, 

that they introduce AUTOSAR into their vehicles. 

Some companies are complaining that, in spite of the 

standard, significant adaptations have to be made for 

particular automakers. 

AUTOSAR is the central standard for automotive software 

and has created a sound basis. It is not being introduced 

overnight, however. This leads to migration scenarios, 

since the new systems have to be compatible with older 

systems. This naturally involves a certain effort. This will 

diminish dramatically, however, the more AUTOSAR-compliant 

components are on board. 

Including plug-and-play? 

The pithy expression “plug-and-play” should be done away 

with. A certain amount of integration will always be required. 

AUTOSAR has created a standard with the methodology 

and system software. This topic is a question of the 

user software. The user software interfaces are defined 

precisely for this. In the medium term, the level of input 

required will diminish. It is about mastering complexity. 

Current models in the compact class have up to 50 control 

units – this is precisely where AUTOSAR will help to master 

the increasing level of complexity in future. 

What will AUTOSAR be working on next? 

Release 4.0 is due to be launched in late 2009. This will be 

a major step, as it will affect three key areas, one of which 

is the functional safety, which has been developed with the 

ISO standard 26262 in mind. Needless to say, we can only 

deal with the parts we know to date, since the standard 

won’t be officially available until 2011. 

We will also be focusing on the topic of multicore. Fields 

of application for multi-processor systems such as these 

can already be seen today in infotainment. 

And, last but not least, the topic of conformance testing. 

Creating a standard only is the first step. It is then a 

question of ensuring that the products conform to the standard. 

Test institutes already exist today that offer such conformance 

tests. 

For AUTOSAR, no general conformance tests exist to date, 

but merely in-house solutions. These are based on the specification. 

To assure the quality of the products and their 

interaction, it is important to define standard tests which 

every product must pass. 

4.0 is not due before late 2009.This is a relatively long 

time... 

The topics of functional safety and multicore constitute a 

major step. In addition, the manufacturers require a stable 

standard before they can start series production. We have 

put out a relatively high number of releases in the last few 

years, which is also quite normal for an entirely new topic. 

In the meantime, the standard however has reached a 

maturity level that revision will only be necessary at prolonged 

intervals. 

I assume that all companies are currently investing 

more in AUTOSAR than they earn from it. Is a breakeven 

point getting closer? 

In our opinion, it doesn’t make sense to take this approach, 

since it’s not a question of “AUTOSAR – yes or no?” AUTO- 

SAR is always only introduced with a change of platform, 

due to the long development cycles and the input required 

for its introduction. As a result, even if control units featuring 

AUTOSAR software were to be serially produced by 

every core member by 2010, the absolute number of units 

will initially be low. However, this will progressively increase, 

at which point we will also see the desired cost advantages 

begin to emerge. 

From what point in time will it be possible to earn 

money with AUTOSAR? 

Standardization has the objective of improving quality and 

reducing the time to market and costs. It will be possible 

to earn money when AUTOSAR has attained a high degree 

of market penetration. 

Dr. Mössinger, thank you for this interview. 

AUTOSAR´S NEW SPOKESPERSON 

The AUTOSAR development partnership 

has appointed Gerulf Kinkelin 

as its new spokesperson. He 

is Innovation Area Manager for 

Electricity, Electronics & Telematics 

at PSA Peugeot Citroën. 

Dr. Stefan Bunzel, Manager Software 

Platforms, Systems & Technology 

at Continental takes over 

as new deputy spokesperson. 

Gerulf Kinkelin



Development of AUTOSAR Software Components 

with Model-Based Design 

To address the challenges of increasing complexity while developing 

and maintaining electronic applications within the automotive 

domain, the companies involved decided to define a standardized 

architecture for electronic control units (ECU). Therefore, 

in 2002 leading OEMs and suppliers established the partnership 

of AUTOSAR (Automotive Open System Architecture) 

The defined architecture with the different software 

layers is divided into three major areas. The 

Application Layer contains the functional applications 

of an ECU network. In the terminology of the standard, 

they are referred to as AUTOSAR Software Components. 

The AUTOSAR Run-Time Environment (RTE) 

layer was introduced to decouple the application software 

from the concrete infrastructure software. Finally, 

the AUTOSAR Basic Software layer between micro-controller 

and the RTE defines the infrastructure software 

both as hardware-dependent and hardware-independent 

non-functional services. 

As mentioned above, the decoupling of functional application 

software and the target hardware is one of the main 

goals of AUTOSAR. To reach this goal, the Virtual Functional 

Bus was introduced. AUTOSAR software components 

implement the Application Layer and encapsulate the functionality 

of a single ECU or an ECU network. These software 

components have well-defined and standardized 

interfaces. Each AUTOSAR software component is dedicated 

to one specific ECU, while one ECU could consist of 

multiple software components. The Virtual Functional Bus 

implements the communication between the different 

AUTOSAR software components regardless of where they 

are located within the vehicle’s ECU network. This concept 

in principle allows integration or transfer of AUTOSAR software 

components anywhere on the network. In the implementation 

phase, the generated runtime environment is a 

specific instance of the Virtual Functional Bus. 

Development of AUTOSAR software 

components 

The concept and benefits of Model-Based Design are even 

more valuable within the context of AUTOSAR, and should 

be applied to even more uses. Once a company has made 

the decision to develop their ECUs following an AUTO- 

SARcompliant process, the design or software engineer 

should not be forced to change his or her workflow in order 

to generate AUTOSAR-compliant software. The Math- 

Works approach based upon MATLAB, Simulink, and Real- 

Time Workshop Embedded Coder for generating AUTO- 

SAR-compliant code follows a transparent and intuitive pro-



Figure 1. DaVinci Architecture export and import into 

MATLAB and Simulink. 


cess, and it supports two different workflows: top-down 

and bottom-up. 

Top-down: From an architecture model 

to an AUTOSAR software component 

In the top-down workflow, system engineers use an architecture 

design tool (known as Authoring Tool in AUTOSAR 

terminology) such as the DaVinci Tool Suite from Vector 

Informatik to design the architecture of a vehicle’s ECU network. 

Of course this does not restrict the possibility to use 

other authoring tools. The engineers then export an XMLdescription 

of the corresponding components: the AUTO- 

SAR Software Component Description. This file contains all 

necessary information about the components such as runnables, 

interface descriptions, data types, and so on. With 

the AUTOSAR solution from The MathWorks, engineers 

can import this XML-file and automatically generate a skeleton 

Simulink model that contains the interface blocks 

(inports and outports) and the AUTOSAR-related settings 

for these objects as defined in the software component’s 

description file. MATLAB API functions allow importing the 

AUTOSAR Software Component Description files and the 

generation of the skeleton model according to the AUTO- 

SAR settings by using the MATLAB command line. Starting 

from this skeleton model, design engineers can develop 

the controller model with Simulink, Stateflow and companion 

blocksets. 

The block structure of the model can remain, and if the port 

structure is the same, engineers do not need to make 

extensive changes. The verification and validation features 

especially can be applied as usual and described in the section 

on Model-Based Design. Typically, the design engineer 

makes enhancements to the model relevant to AUTOSAR, 

for example by introducing additional runnables or interface 

objects. In this particular case he or she has to make 

corresponding settings to ensure that the generated code 

is compliant to the standard and fits into the additional software 

environment containing the run-time environment 

and hardware-related components from the basic software 

layer. These settings can be made via appropriate configuration 

parameter dialogs. For the code generation, the corresponding 

AUTOSAR System Target in Real-Time Workshop 

Embedded Coder needs to be selected. 

Bottom-up: Reusing legacy models to 

generate AUTOSAR-compliant code 

Because Model-Based Design is a well established process 

in the automotive industry, companies usually have 

an extensive library of mature and extensively tested 

models. It is important that these models can be reused to 

target different platforms such as AUTOSAR without any 

changes to the models’ blocks. 

The bottom-up workflow requires the same AUTOSAR configurations 

as described in the top-down workflow. In particular, 

the interface objects need to be configured to ensure 

that the generated software component can be integrated 

properly. In addition to the code files, an updated AUTO- 

SAR software component description file in XML format 

will also be generated automatically. 

Guido Sandmann, Automotive Marketing 

Manager, EMEA – The MathWorks 

Joachim Schlosser, Senior Team Leader 

Application Engineering – The MathWorks



Infotainment in an 

AUTOSAR environment 

Since the 1990s, automobiles have been increasingly dominated by electronics 

and associated software. Now, automotive innovations without 

modern electronics are barely conceivable. The breakneck development of 

software-based systems in nearly all areas of life continues to drive this 

trend, presenting the automobile industry with a difficult dilemma. On the 

one hand, customers expect new, innovative and directly accessible functions 

as well as safe and environment-friendly vehicles. On the other 

hand, every additional component increases development, production and 

warranty costs. In this environment, the ability to implement innovations 

cheaply and quickly can represent a decisive competitive advantage. 

Technical background 

Introducing and networking electronic components 

presented the automobile industry with new challenges. 

System complexity increased with the number of 

devices. The development process became more complicated, 

installation space became increasingly restricted 

and the wiring harness grew into one of the heaviest 

and most difficult components. Not least, the entire 

system became increasingly difficult to manage and 

after-sales service had to deal with problems arising 

from the electronics and the software. Another problem 

during this phase arose from the way automobile manufacturers 

organised development and development processes, 

where every new function also meant a new 

control device that then had to be developed by one of 

the manufacturer’s component suppliers. This process 

created a wide range of manufacturer-specific and vehicle-specific 

solutions and almost all the development 

expertise stayed in the component supply industry. The 

AUTOSAR (AUTomotive Open Software ARchitecture) 

development partnership was founded in order to change 

this situation. It has dealt with the standardisation of 

the automobile software platform and the associated 

processes and tools since 2002 and now specifies the 

standard for next-generation vehicles. Despite AUTO- 

SAR’s successes, a few important problems remain 

unresolved. The standards can be applied to typical vehicle 

functions, but in the areas of infotainment and connectivity 

they exclude precisely those areas which are 

most driven by the entertainment and telecommunications 

industries and in which customers experience 

innovations most directly and immediately. The data



Figure 1::The COQOS platform´s unique architecture: 

connectivity of these domains could also be extremely 

useful in many different ways when applied to vehicle 

functions, whether in after-sales service for diagnostics 

or software updates or in driver assistance systems that 

could function more effectively with data from the navigation 

system or even from the Internet. 

OpenSynergy’s vision is to bring these two worlds together 

safely and reliably. 

The COQOS operating system 

COQOS was designed as a universal automotive operating 

system with the following premises: 

100% AUTOSAR compliance both in its architecture 

and in its processes 

Compliance with the relevant automotive standards 

Open system interfaces in the area of infotainment and 

connectivity 

A platform approach that drastically shortens the software 

development cycle, especially in the areas of infotainment 

and connectivity 

Reduction in the number of control devices, despite 

the growing number of functions 

Greatest possible openness and future-proofing 

Maximum reusability and scalability 

Flexibility due to modular approach 


Implementation of this concept (i.e. joining 

these two worlds) required intensive 

expertise both in AUTOSAR and in telecommunications. 

The most important 

basis for COQOS is virtualisation - a technology 

that also developed into a trend 

last year in the world of home and office 

computing. The objective of virtualisation 

is to combine or distribute the different 

resources on a computer. The objective in 

COQOS is to distribute the resources on 

a control device based on a cost-efficient 

system-on-chip between infotainment 

and connectivity on the one hand, and 

AUTOSAR applications on the other hand. 

At the same time, it is important to ensure 

that there is no interference between the two software 

worlds in order to meet the automobile industry’s specific 

requirements for safety, start-up behaviour etc. and the 

functioning of vehicles in all conditions. In addition to these 

self-defined requirements, COQOS must, of course, also 

meet familiar requirements such as on/off behaviour, diagnostic 

capability, etc. Another clear goal during development 

was to ensure that virtualisation would create the 

minimum possible additional strain on system resources. 

To meet all these requirements, the AUTOSAR modules 

that are required for the individual case at hand are combined 

with a Micro Operating System that also provides a virtualisation 

layer. This Micro Operating System already provides 

basic mechanisms for the secure construction of the 

overall system (such as memory protection and timing protection), 

meeting aspects of functional safety and security 

from external attacks. While the automotive world is defined 

extensively with AUTOSAR, the infotainment world 

remains relatively undefined in the different systems to 

date. QNX is widespread in current systems, but there are 

also already approaches based on Embedded Linux or Windows 

Automotive. As a typical embedded operating 

system, QNX comes from the industrial milieu and the 

inclusion of functions from consumer electronics is a development 

intensive process. Windows and Linux both come 

from the area of entertainment electronics and therefore 

bring with them all the interfaces and technologies (such 

as WiFi or 3D graphics). Integrating them with the vehicle 

infrastructure, however, is development intensive and will 

provide every function developer in the automotive environment 

with problems. COQOS will combine infotainment 

operating systems with standard-compliant AUTO- 

SAR basis software. Functional distribution of the components 

retains the advantages of the existing systems: 

 

The AUTOSAR modules meet specifications, and can 

therefore be used for all automotive applications and 

Figure 2: COQOS enables structured development processes 

© automotive


 

 

provide a tool-based configurable 

RTE as a functional interface. 

In the infotainment area it is possible 

to use operating systems available 

on the market. There is no need 

for specific changes to the automobile 

environment. Functions can be 

implemented in the existing application 

interfaces. 

As an additional module, COQOS 

contains a Micro Operating System 

that provides the virtualisation layer 

for the infotainment system and 

enabling secure and independent 

parallel operation on a shared hardware 

platform. 

The first COQOS implementation will be 

Linux-based in order to enable access to 

the widest possible spectrum of function 

providers from the areas of mobile 

communications and entertainment 

electronics. Linux also offers many 

benefits for development, such as open 

access to the source code, multipleaccess 

development environments, etc. 

In later implementations, it will also be 

possible to apply other infotainment 

operating systems where required by 

customers. 

Solution examples for current 

and future systems 

COQOS was designed as a software 

construction kit and is based on multiple 

modules that can be used to design the 

relevant solution. The following list provides 

an idea of the wide range of different 

solutions: 

1. AUTOSAR basic software 

The construction kit can, of course, also 

be implemented without infotainment 

components. Unlike other systems, 

COQOS is AUTOSAR basic software 

and therefore includes the different 

listed safety mechanisms from AUTO- 

SAR 3.1 onwards. 

AUTOSARl AUTOMOTIVE 2008l 33 

2. Connection of existing, complex, 

non-AUTOSAR-compliant functions 

with AUTOSAR 

During the development of AUTOSAR, 

many automobile manufacturers developed 

functions that can be easily adapted 

to the standard. Other functions 

have already been developed according 

to the standard and can use an RTE as a 

system interface. If you want to combine 

both functions without starting new 

developments, you would have to install 

two control devices and connect them 

via an appropriate bus (usually CAN). 

COQOS allows their combination on 

shared hardware as non-AUTOSAR 

functions can be included on the virtualisation 

layer. 

3. Infotainment with an AUTOSAR environment 

This configuration provided the basic idea 

for COQOS and has already been described 

in detail. COQOS combines two software 

systems with different, non-functional 

requirements, separates them 

securely and enables targeted and managed 

communication. The performance of 

modern embedded processors can be 

fully employed, intelligent functional 

assignment makes it possible to save on 

control devices throughout the overall 

system. 

These are probably the three most important 

COQOS-based solution approaches. 

Others are still being developed. The 

design of the development process, partitioning 

of the software architecture and 

high quality standards ensure that the 

system is strongly oriented towards reusability. 

Stable, standard-based application 

interfaces make it possible to continuously 

integrate new functions in ever 

shorter development times. COQOS 

ensures a stable system basis for very 

different vehicles, making it possible to 

concentrate on the important goals of 

developing new, exciting and affordable 

functions for next-generation vehicles. 

The COQOS development 

tool 

The development environment is an 

important, albeit often neglected, component 

of complex software systems. It 

plays an important role in managing 

complexity in the development process 

and also in providing targeted and accurate 

design for the latest vehicle software. 

The COQOS development environment 

had to meet similar requirements 

to COQOS itself. The tools needed 

to be modular, multi-purpose, 

expandable and they needed a basis 

that was already widely available on the 

market. As well as easy configurability, 

support for required development 

methods was also given high priority. 

Java and Eclipse were therefore used to 

Universelle 

Automotive 

Plattform 

Entwicklungs - 

plattform für alle 

gängigen automotiven 

Bussysteme 

Board-Support- 

Package für die einfache 

Entwicklung 

kundenspezifischer 

Anwendungen 

Verschiedene Transport- 

und Diagnoseprotokolle 

verfügbar 

PC-basierte 

Entwicklungsum - 

gebung 

Leibnizstr. 15 · D-88250 Weingarten 

Tel.: +49-(0)7 51 / 5 61 46-0 

Fax: +49-(0)7 51 / 5 61 46-29 

Internet: www.ixxat.de



reflect in the tool chain the methodology defined by AUTO- 

SAR for developing the basic software. Because the 

COQOS development environment is used to develop both 

AUTOSAR software and an infotainment platform, theoretical 

AUTOSAR approaches were developed further in this 

area. Assignment to the different areas is performed in the 

development environment, as is assignment of the required 

sub-functions. As the first module of a customer-ready 

solution from the COQOS development environment, 

QONFORMAT is a tool that can be used to demonstrate 

AUTOSAR-compliance of basic software modules. 

Benefits for consumers 

The overriding objective when developing COQOS was to 

achieve a high level of benefit for consumers (i.e. buyers of 

modern automobiles). COQOS was designed to enable the 

integration of new, exciting functions without simultaneously 

increasing costs throughout the overall system. This 

can only be achieved if it is possible in the long term to reduce 

the hardware in the vehicle and drastically shorten the 

development cycle for software-based functions. Standardisation, 

reusability and separation of hardware and software 

are the keys to achieving our goal. COQOS enables 

these things. This will make it possible to implement new 

functions in mass production that were previously possible 

only in the luxury sector. Consistent compliance with the 

relevant software development standard will also make it 

ADVERTISERS 

Bosch GmbH, Stuttgart . . . . . . .13 

Braun GmbH, Waiblingen . . . . .26 

dSpace GmbH, Paderborn . . . . . .2 

Eberspächer Electronics 

GmbH & Co. KG, Göppingen . . .23 

ELEKTROBIT Automotive GmbH, 

Erlangen . . . . . . . . . . . . . . . . . . .11 

ELMOS Semiconductor AG, 

Dortmund . . . . . . . . . . . . . . . . . .3 

ETAS GmbH, Stuttgart . . . . . . . .35 

IXXAT Automation GmbH, 

Weingarten . . . . . . . . . . . . . . . .33 

Mentor Graphics (Deutschland) 

GmbH, München . . . . . . . . . . . .9 

Softing AG, Haar . . . . . . . . . . . .15 

TietoEnator Deutschland GmbH, 

Stuttgart . . . . . . . . . . . . . . . . . . .21 

TTTech Computertechnik AG, 

A-Wien . . . . . . . . . . . . . . . . . . . .5 

Vector Informatik GmbH, 

Stuttgart . . . . . . . . . . . . . . . . . . .36 

YOKOGAWA GmbH, 

Herrsching . . . . . . . . . . . . . . . . .19 

Editors 

Dipl.-Ing. (FH) Klaus Oertel (editor in chief), 

Phone +49/89/99830-425, oertel@hanser.de 

Dipl.-Ing. (FH) Wolfgang Lachermeier, 

lachermeier@ hanser.de 

Stefanie Kraus (Assistent) 

Phone +49/89/99830-652, skraus@hanser.de 

Kolbergerstr. 22, 81679 Munich, 

E-Mail: automotive@hanser.de 

Advertising department 

Lutz Benecke (Manager), Phone +49/89/ 

99830-207, benecke@hanser.de 

Renate Hofbauer (Assistant), Phone +49/89/ 

99830-649, hofbauer@hanser.de 

Fax: +49/89/99830-623 

Publisher 

Carl Hanser Verlag GmbH & Co. KG, 

Kolbergerstr. 22, D-81679 Munich or 

P.O. Box 86 04 20, D-81631 München, 

Phone +49/89/99830-0, Fax +49/89/984809, 

www.hanser.de 

Managing Directors 

Wolfgang Beisler, Stephan D. Joss, 

Michael Krüger 

Publishing Director 

Michael Himmelstoss 

Sales Department 

Susanne Wolf (Head of Department), 

Phone +49/89/ 99830-105, wolf@hanser.de, 

Nina Reiser (Abo-Service), 

Phone +49/89/99830-111, 

E-Mail: abo-service@hanser.de 

Production Manager 

Hadrian Zett (responsible), 

Phone +49/89/9930-420 

possible to implement safety concepts and driver assistance 

functions in smaller vehicles, making them safer in 

traffic. 

Frank-Peter Böhm is General Manager and 

CEO of OpenSynergy GmbH, Berlin. 

Rolf Morich is General Manager and COO of 

OpenSynergy GmbH, Berlin. 

Dr. Stefaan Sonck Thiebaut is General 

Manager and CTO of OpenSynergy GmbH, 

Berlin. 

Layout 

Design Concept Krön, Gutenbergstr. 9, 

D-82178 Puchheim 

Print: 

Sellier Druck GmbH, Angerstr. 54, 

D-85354 Freising 

Printed in Germany 

Copyright and Publishing Rights 

The publication and all individual articles and 

illustrations contained herein are protected by 

copyright. 

Upon an article being accepted for publication, 

the right of publication, as well as right of translation, 

of granting reproduction licences, of storage 

in electronic retrieval systems, 

of producing special impressions, photocopies 

and microcopies are transferred to the 

publisher. 

Any utilization thereof outside the limits of the 

copyright act is forbidden without the written 

permission of the publisher. 

© Copyright by Carl Hanser Verlag, 

Munich 2008 

Descriptive Names 

The use of general descriptive names, proprietary 

names, trade names, commercial designations 

or the like in this publication in noway 

implies that such names may be used freely: 

these are often legally protected, registered 

trademarks, even if not designated as such. 

While the advice and informations in this journal 

are believed to betrue and accurate at the date 

of its going to press, neither the authors, the 

editors, nor the publisher can accept any legal 

responsibility for any errors or omissions that 

may be made. The publisher makes nor warranty, 

express or implied, with respect to the material 

contained herein.



A Distributed Navigation Application 

enabled by FlexRay 

FlexRay has already been introduced in BMW’s X5 and X6 series, 

where it is used for dynamic suspension control. The upcoming BMW 

7-series will incorporate FlexRay, with further cars from other OEMs 

expected to follow. FlexRay’s new communication features enable 

a wide range of functions, which are no longer bound to a single control 

unit. These developments raised the questions: Is FlexRay suitable 

for use in a navigation system? Can FlexRay be used to transfer 

moving image data between applications? This feasibility study 

has been undertaken to answer these questions in relation to a navigation 

application. 

FlexRay Capabilities 

FlexRay provides a two channel communication, with each 

channel having up to 10 Mbit/s bandwidth, which is used 

for either redundant transmission for safety-relevant data 

communication or to double the bandwidth to 20 Mbit/s. A 

fixed time division multiple access (TDMA) scheme ensures 

fixed communication latency. Each node sends data at 

a specific point in time, which is scheduled prior to system 

run-time. This is called time-triggered communication. The 

static segment of a communication cycle uses TDMA. 

The flexible time division multiple access (FTDMA) scheme 

enables sporadic message transfer comparable with 

today’s CAN systems, where a message competes with 

other messages during system run-time to get communication 

link access. The dynamic segment of a FlexRay communication 

cycle makes use of FTDMA. 

Navigation data 

transfer via Flex- 

Ray 

FlexRay supports many different topologies ranging from 

pure linear bus structure over active or passive star to 

mixed bus-star configurations of the cluster nodes. 

Future In-Car Network Topologies with 

FlexRay 

Due to its high bandwidth, the time-trigged communication 

feature and its support of different topologies, FlexRay 

enables the development of new communication architectures. 

Figure 2a shows the classical domain driven topology 

containing a central gateway. Here, FlexRay is used 

for chassis and powertrain control applications. Figure 2b 

depicts a different network architecture. It contains 

domain-specific gateways with FlexRay as the central data 

backbone, connecting all domains. Both concepts have 

advantages, however, the domain-specific gateway con-


cept provides a better scalability 

over functions and car models. For 

the distributed navigation application 

this architecture concept was 

abstracted to two single network 

nodes, one for route calculation 

including map storage and one for 

display purposes. 

Prototype System 

Overview 

Hardware 

Fujitsu starter kits have been selected 

for the prototype system. One 

SK 91F467 FlexRay is used to transmit 

the graphic data to the second 

node. This second node consists of 

an SK 91F467 FlexRay and the 

Cremson-Lime starter kit, used for 

the display of the received data. 

The SK 91F467 FlexRay supports 

the 32 bit MB91F467D MCU and 

the MB88121 FlexRay communication 

controller (CC). In addition, a 4 

MB SRAM and a 16 MB Flash have 

been specially hooked for the prototype 

system and can be addressed 

as external memory. The Flex- 

Ray transmission uses the AS8221 

transceiver from AMS. The graphic 

portion of the system is supported 

by the Cremson-Lime starter kit, 

which comes with an MB86276, a video input processor 

(VIP) and 64 MB SD-RAM. Using common plug connections 

such as DVI and LVDS, it is easy possible to connect 

standard displays. The dataflow is controlled by the 

MB91F467D series as the host MCU, which provides three 

CAN interfaces, 6 LIN USART and a parallel bus interface. 

This interface connects the MB88121 FlexRay CC to the 

host MCU. Based on the E-RAY core, licensed from Robert 

Bosch [2], the MB88121 CC supports 2-channel operations, 

and with more than 8 kB of message buffer memory, 

up to 128 different identifiers can be supported. The 

device meets the latest protocol specification, as defined 

by the FlexRay consortium: 2.1. As the graphic data is received, 

it is passed to the MB88276 VIP, which is also connected 

to the host MCU via a bus interface. 

Software 

The prototype system (Figure 3) developed within the feasibility 

study contains two FlexRay nodes. The control node 

is responsible for accessing the mass data storage device 

with the map data and the processing of GPS data for the 

route calculation. Due to their complexity, the GPS and 

route calculation modules had to be simulated in an easier 

way, but this does not really influence the conclusions gained 

by this prototype. The simulation is based on a pre-defined 

list of points along the route. These points correspond 

to a fixed X/Y-position in the whole map source and need 

an interpolation algorithm. 


Figure 2a: A central gateway architecture with FlexRay 

Figure 2b: FlexRay communication backbone architecture 



The second node has been called the display node. It processes 

the received commands and map data and changes 

the information on the connected display accordingly. 

When the navigation starts, the map of the current position 

is completely transferred only once. As the position of 

the vehicle changes in the simulation, new sections of the 

map must be displayed. In order to reduce the required 

bandwidth for the graphic data transmission the whole 

map is not transferred at every change. Instead, only the 

new pixel rows and/or columns are transmitted. The display 

node receives a command to scroll down the appropriate 

number of pixels on the displayed map in the appropriate 

direction and fills the gaps in this new map section with the 

received row or column of graphic data. Such a command 

could look like ‘move map in +X direction for the distance 

of two pixels’. The old data that is no longer used in the 

display is not retained to reduce the memory requirements 

of this node. If, during this process, an error occurs, a complete 

part of the map will be sent to the display node so 

that an error-free display is realised. 

As well as the graphic information, command and control 

data is also transferred. For example when the information 

to turn in another direction is sent, the display node will show 

a pop-up window in the display with an arrow indicating the 

new direction. This command and control data of the control 

node and the responses of the display node are all transferred 

in the static segment. The graphic data uses the dyna-



Figure 3: System set-up for distributed navigation application 

with FlexRay 


Figure 4: Actual bandwidth over time 


mic segment because it must only be transferred sporadically, 

as the position of the vehicle changes. 

Results and Outlook 

This prototype was intended for the examination of bandwidth 

requirements for an automotive navigation application 

using distributed embedded systems connected via 

FlexRay. For this purpose a PC with appropriate diagnostic 

software monitored the FlexRay bus and calculated the 

required bandwidth averaged over a certain amount of 

time. Figure 4 is a diagram of the graphic data in the dynamic 

segment and the average net bandwidth utilisation. 

The prototype needs: 

- 32-kbit/s in the static segment (fixed) and 

- 90-kbit/s in the dynamic segment (averaged) 

The bandwidth for the graphic data transfer depends on 

various factors. If a map view with a higher zoom level is 

used, the map must be scrolled faster. This consumes 

more graphic data per time. The (averaged) peak bandwidth 

for the graphic data transfer could also be lowered down 

to a certain limit. The whole transfer process will last longer 

if the maximum amount of data is not sent in each Flex- 

Ray cycle. The decision for a peak bandwidth reduction will 

also depend on the type of other communications transferred 

on the FlexRay network in the dynamic segment. 

Finally, all the graphic data is uncompressed in this implementation, 

which of course can be enhanced. There are a 

lot of equally coloured areas in typical navigation maps. 

Therefore the achievable compression factor would lead to 

an even lower bandwidth requirement. Thus the value of 

90-kbit/s for the bandwidth derived from this prototype can 

only be treated as one possibility. 

Apart from the compression of graphic data, the implementation 

of a data buffer in the display node would also 

result in better overall system performance. This data buffer 

may contain predicted graphic data that was sent at low 

priority to improve bus utilisation. The control node can 

send graphic data beforehand, because it ‘knows’ which 

data will be needed next, unless the driver does not follow 

the directions, in which case the data is discarded. 

Acknowledgements 

The authors would like to thank Vector Informatik and 

Eberspächer Electronics for their support of the feasibility 

study by providing their latest software tools for FlexRay 

measurement and FlexRay configuration. 

References 

[1] C. Eyrich, Prototypische Untersuchung zur Übertragung von 

Grafikdaten über FlexRay (in German), Diploma Thesis, University 

of Applied Sciences Aschaffenburg, 2008 

[2] Robert Bosch GmbH, E-Ray FlexRay IP-Module, User’s 

Manual, Revision 1.2.6, 2007 

Prof. Dr.-Ing. J. Abke, Professor of Computer 

Sciences and Electrical Engineering Basics 

at the University of Applied Sciences Aschaffenburg, 

Head of the Laboratory for Embedded 

Systems 

Christian Eyrich 

Junior Application Engineer 

Automotive Business Unit 

Fujitsu Microelectronics Europe GmbH 

Matthias Steeg 

Application Engineer 


Fujitsu Microelectronics Europe GmbH 

Wolfgang Wiewesiek 

Manager Automotive Networks 


Fujitsu Microelectronics Europe GmbH

Download - HANSER automotive

Create successful ePaper yourself

Delete template?

Save as template?