with LABCAR - HANSER automotive

S PECIAL E DITION 

automotive 

H A N S E R 

electronics systems 

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

6 

FlexRay 

with LABCAR 

FlexRay from first launch to a defacto standard · FlexRay Residual Bus Simulation 

on HiL Testing Systems· FlexRay Becomes Daily Routine · FlexRay Protocol Implementation 

Analysis – The Story · ECU Tests for FlexRay Applications · Easy access to FlexRay · Testing 

CAN and FlexRay Networks · FlexRay in AUTOSAR · Body and gateway microcontroller 

with embedded FlexRay · FlexRay Controller - Integrated or Discrete? · FlexRay Products

FLEXRAYl AUTOMOTIVE 

2007l3 


FlexRay 

from first launch 

to a defacto 

standard 

The FlexRay consortium has 

already made two publicly 

released versions of the Flex- 

Ray specifications. Components are 

available, and parts designed for 

these applications are in use in a first 

application – the 2007 BMW X5 

variable damper suspension system. 

Several other applications are now 

under development by multiple 

OEMs. 

So the usage of FlexRay will heavily 

increase in the near future and there is 

absolutely no question that it has been 

a successful launch of a new communication 

standard and it’s on its way to 

becoming the defacto standard within 

this domain. 

Peter Hansson, GM (Saab), 

is Consortium Speaker of the 

FlexRay Consortium 

One factor in the success of this launch has been the formal release of the 

conformance test suites for communication controllers and physical layer 

devices. Now semiconductor suppliers can design their silicon solutions to 

be confirmed and approved by the conformance test partners. This will 

enhance the interoperability and the overall system behavior of a FlexRay in 

vehicle architecture. 

Meanwhile the Consortium is maintaining both the protocol and the test specifications 

and is planning to introduce several enhancements. The main 

goals of the consortium and the driver of the development plan is to develop 

a new specification set by the end of the current consortium agreement. 

The consortiums work has been influenced by the input from other consortia 

such as Autosar and Jaspar and it has always been the ambition to strengthen 

these relationships. In 2007 the consortium has been working on forms 

and procedures to establish a closer cooperation and a first workshop meeting 

together with Jaspar delegates in conjunction with the FlexRay Product 

day. These activities are welcome initiatives to strengthen the standard and 

to limit the proliferation in this domain. 

The committance of OEMs, such as GM, to put FlexRay into series production 

guarantees for the success of FlexRay as a key building block within the 

vehicle electrical architecture infrastructure.

4lA UTOMOTIVE 2004l 

CONTENT 

SPECIAL EDITION FLEXRAYl SPECIAL AUTOMOTIVE EDITION FLEXRAY 

2007 


3 FlexRay from first launch to 

a defacto standard 

Preface by Peter Hansson, spokesperson for 

the FlexRay Consortium 

6 ETAS: FlexRay Residual Bus Simulation 

on HiL Testing Systems 

Vehicle dynamics ECUs with FlexRay communications are being 

tested on facilities equipped with LABCAR Hardware-in-the Loop 

systems 

10 Vector: FlexRay Becomes Daily Routine 

CANoe.FlexRay enables engineers to solve both routine and challenging 

FlexRay tasks 

13 Ertesis: FlexRay Protocol Implementation 

Analysis – The Story 

Finding implementation flaws was a really hard job until today. 

Now it will become common practice by stimulation with arbitrary 

FlexRay streams while simultaneously recording raw bus communication 

data. 

17 dSpace: ECU Tests for FlexRay Applications 

Test methods and restbus simulation 

21 TZM: Easy access to FlexRay 

Turn-key Platform for FlexRay rookies 

22 TTTech Automotive: Testing CAN and 

FlexRay Networks 

Portable Gateway Tool for Testing CAN and FlexRay Networks 

24 Fujitsu: FlexRay in AUTOSAR 

Solutions for both standard 

26 NEC: Body and gateway microcontroller 

with embedded FlexRay 

FlexRay evaluation board and AUTOSAR starter kit 

29 Infineon: FlexRay Controller - 

Integrated or Discrete? 

Engineers spoilt for choice 

32 Products 

42 masthead / index of advertisers 

29 

13 

Finding implementation flaws will 

become common practice by stimulation 

with arbitrary FlexRay streams while 

simultaneously recording raw bus 

communication data. 

At Robert Bosch Chassis Systems Control, 

vehicle dynamics ECUs with Flex- 

Ray communications are being tested 

on facilities equipped with LABCAR 

Hardware-in-the Loop systems. While 

development engineers use the same 

systems for function and release 

testing, manufacturing deploys them 

for testing ECU warranty returns. 

What are the advantages for 

automotive system designers 

of using a discrete FlexRay 

communications controller 

and one integrated into its 

high end 32-bit microcontroller 

family. 

6

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

4lA UTOMOTIVE 2004l 

CONTENT 

SPECIAL EDITION FLEXRAYl SPECIAL AUTOMOTIVE EDITION FLEXRAY 

2007 


3 FlexRay from first launch to 

a defacto standard 

Preface by Peter Hansson, spokesperson for 

the FlexRay Consortium 

6 ETAS: FlexRay Residual Bus Simulation 


Vehicle dynamics ECUs with FlexRay communications are being 

tested on facilities equipped with LABCAR Hardware-in-the Loop 

systems 

10 Vector: FlexRay Becomes Daily Routine 

CANoe.FlexRay enables engineers to solve both routine and challenging 

FlexRay tasks 

13 Ertesis: FlexRay Protocol Implementation 

Analysis – The Story 

Finding implementation flaws was a really hard job until today. 

Now it will become common practice by stimulation with arbitrary 

FlexRay streams while simultaneously recording raw bus communication 

data. 

17 dSpace: ECU Tests for FlexRay Applications 

Test methods and restbus simulation 

21 TZM: Easy access to FlexRay 

Turn-key Platform for FlexRay rookies 

22 TTTech Automotive: Testing CAN and 


Portable Gateway Tool for Testing CAN and FlexRay Networks 

24 Fujitsu: FlexRay in AUTOSAR 

Solutions for both standard 

26 NEC: Body and gateway microcontroller 


FlexRay evaluation board and AUTOSAR starter kit 

29 Infineon: FlexRay Controller - 


Engineers spoilt for choice 

32 Products 

42 masthead / index of advertisers 

29 

13 

Finding implementation flaws will 

become common practice by stimulation 

with arbitrary FlexRay streams while 

simultaneously recording raw bus 

communication data. 

At Robert Bosch Chassis Systems Control, 

vehicle dynamics ECUs with Flex- 

Ray communications are being tested 

on facilities equipped with LABCAR 

Hardware-in-the Loop systems. While 

development engineers use the same 

systems for function and release 

testing, manufacturing deploys them 

for testing ECU warranty returns. 




communications controller 

and one integrated into its 

high end 32-bit microcontroller 

family. 

6

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

6lA UTOMOTIVE 2007l SPECIAL EDITION FLEXRAY 


FlexRay Residual Bus Simulation 


At Robert Bosch Chassis Systems Control, vehicle dynamics ECUs 

with FlexRay communications are being tested on facilities equipped 

with LABCAR Hardware-in-the Loop systems. While development 

engineers use the same systems for function and release testing, 

manufacturing deploys them for testing ECU warranty returns. 

The HiL test bench simulates static and dynamic 

events occurring within the DVE (driver, vehicle, 

environment) surroundings of the ECUs to be 

tested. This is accomplished by simulating the ECU environment 

through the use of electrical loads and a DVE 

model. HiL test benches provide a liberal degree of latitude 

for ECU testing that is both free of hazards and 

reproducible. 

Robert Bosch Chassis Systems Control deploys LABCAR 

testing systems by ETAS, on which the DVE model runs in 

a real-time environment on a standard PC (LABCAR-RTPC). 

The I/O signals obtained from the ECU are exchanged with 

the model in closed-loop fashion through dedicated interfaces 

in the LABCAR hardware. The attendant cycle times 

amount to a few milliseconds. With the aid of the LABCAR- 

OPERATOR software, the experiments can be controlled

SPECIAL EDITION FLEXRAYl AUTOMOTIVE 

2007l7 


Figure 1:The virtual replication of bidirectional ECU communications and the linking 

to an implemented network subsystem is known as residual bus simulation. 

interactively by the user by means of a host computer. 

Another control option is the use of test automation. 

As a component of DVE simulation, residual bus simulation 

replaces non-existent physical ECUs with their simulated 

counterparts. Using an appropriate interface, the host computer 

running the simulation both transmits the signals of 

the virtual nodes via the data bus and receives messages 

from the ECU under test. 

The LABCAR-RTPC FlexRay interface 

Specifically for the purpose of FlexRay residual bus simulation 

on the LABCAR-RTPC, Electrobit (EB) formerly 

DECOMSYS has developed the EB5100 FlexRay-PCI Interface 

Board. Installed in the LABCAR-RTPC, this board converts 

the physical signals of the environment model to 

transport data types. The signals are packed in FlexRay frames, 

which are transmitted in accordance with predetermined 

timing information. The EB5100 module is also capable 

of receiving analog signals: Frame data is passed on to 

the model in the form of receiving FlexRay signals. In the 

subsequent calculation cycle, the model returns 

updated data to the FlexRay bus through the 

interface. 

To relieve the LABCAR-RTPC of the computation-intensive 

FlexRay communications 

task and, at the same time, 

decouple the model calculations 

from the FlexRay clock cycle, the 

EB5100 board employs a powerful 

MPC5200 PowerPC processor. This enables 

the board to handle all FlexRay communications, 

including scheduling tasks. In addition, the board handles 

system services, such as network management, or calculating 

the values of the Alive Counter and the Application 

CRC. To this end, the user can store calculation algorithms 

in mostly OEM-specific Target User Modules in a reserved 

area of the board’s firmware. 

The EB5100 board is equipped with two communications 

controllers. Using the E-Ray IP, these are programmed in an 

FPGA and are therefore easily 

up-dated. The data bus is connected 

by means of exchangeable 

driver modules (TJA1080 

by default). 

With the aid of the two communications 

controllers, Flex- 

Ray communications can be 

started and synchronized independently 

of the unit being 

tested. During a test, this also 

presents an easy way of switching 

back and forth between a 

virtual node being serviced by 

one of the controllers and a real 

system. 

By simulating the signals present 

onboard a vehicle, the 

© automotive 

EB5100 board makes it possible 

to operate a FlexRay ECU 

on the testing system. In addition, it is possible to test ECU 

behavior during vehicle startup, while synchronizing bus 

communications, and in the event of a fault occur-rence. 

To this end, it is possible, on the one hand, to hide not only 

single frames but also entire bus nodes. On the other hand, 

the model’s full access to all of the signals, plus the target 

user modules, enables the generation of implausible 

values, e.g., those of sensors or checksums, and the subsequent 

observation of an ECU’s response to the same. 

The FlexRay module on the EB5100 board is manufactured 

to the PMC (PCI mezzanine card) standard. This makes it 

possible to adapt carrier boards for other backplane bus 

systems, such as compact PCI, PXI, or VME, to the module. 

As a result, Robert Bosch Chassis Systems Control can 

deploy the very same FlexRay residual bus simulation in 

other environments, such as endurance testing systems, 

for example. 

Figure 2:The EB5100 FlexRay interface board is 

a PMC-based module that is suitable for use 

with a variety of carrier boards.The 

EB5100 is equipped with two 

E-Ray communications 

controllers.



Configuring the 

FlexRay residual 

bus simulation 

The FlexRay residual bus simulation 

is configured in five steps. 

Step one requires the use of the 

EB Busmirror tool, which imports 

the communication matrix of the 

respective vehicle project in the 

FIBEX format. In addition to 

FIBEX version 2.0.1, the tool supports 

FIBEX+, providing AUTO- 

SAR-compliant processing of 

PDU signals. The Busmirror uses 

an extract from the FIBEX information 

to generate an XML file 

(FlexRay config-uration), which 

describes the avail-able FlexRay 

signals and application-specific 

data for the purpose of mapping 

the same to the model. 

Step two consists of mapping the 

Figure 3: LABCAR Hardware-in-the-Loop (HiL) test bench with FlexRay residual FlexRay signals to the signals of 

bus simulation.The intelligent FlexRay interface EB5100 is installed in the form of the LABCAR model. In step three, 

a PCI board in the real-time PC (LABCAR-RTPC) of the system performing the test. based on the mapping rule and 

The LABCAR-OPERATOR software running on the host computer comprises the the FlexRay configuration, a C 

user interface of the HiL system.The EB Busmirror tool configures both residual module containing the attendant 

bus simulation and EB5100 interface board. 

variables is generated. It renders 

© automotive FlexRay communications manipulable 

and integrates them with 

the DVE model. At Robert 

Bosch Chassis Systems 

Control, the C modules 

are held in a central database; 

after a quality assurance 

procedure, they are 

available for use by all 

LABCAR test benches. In 

step four, the configuration 

for the target user 

modules of the EB5100 

board, such as Alive 

Counter, Application CRC, 

or Network Management, 

are generated on 

the basis of the FlexRay 

configuration in accordance 

with user specifications. 

To support steps 

one through four, Robert 

Figure 4: Decoupled timing between the model simulation on the LABCAR-RTPC and the Bosch Chassis Systems 

FlexRay communication cycle.The EB5100 FlexRay interface board runs in synch with the Control has developed 

FlexRay clock cycle. Independently of the same, the LABCAR-RTPC handles the calculations proprietary Perl tools. In 

of the environment model on the basis of the control cycle.The FlexRay signals are transferred 

through an intermediate memory. In the event that future applications re-quire the exeror 

uses the configuration 

step five, the EB Busmircution 

of the model in synch with the FlexRay cycle, the time base of the EB5100 board files for the Target User 

may be made available to the LABCAR-RTPC and passed on to the HiL computer. 

Modules in conjunction 

© automotive with the FIBEX data to 

generate the firmware for


FLEXRAYl AUTOMOTIVE 2007l 9 

the EB5100 board. If required, this step can be preceded 

by the manual shifting of FlexRay frames between the two 

FlexRay controllers. It is also possible to correct any data in 

the FIBEX file that was found to be incomplete or faulty. 

Deployment in production 

FlexRay residual bus simulation is already successfully 

deployed on Robert Bosch Chassis Systems Control’s 

LABCAR test benches in several customer projects. The 

FlexRay integration fulfills Robert Bosch Chassis Systems 

Control’s expectations of a flexibly configurable HiL 

system: The FlexRay interface is fully integrated with the 

LABCAR-RTPC. It encapsulates the FlexRay communications 

and enables access to all FlexRay signals at runtime. 

The configuration for the residual bus simulation can be 

generated from the communication matrix by means of a 

consistent tool suite and made centrally available. If test 

automation is required, the parameterized model integration 

of FlexRay communications can be used to control the 

residual bus simulation. 

Deployment as a standard product 

ETAS – as the expert for HiL testing systems, and Elektrobit 

(EB) formerly DECOMSYS – as the pioneer of FlexRay technology, 

will jointly market the FlexRay residual bus simulation 

for LABCAR testing systems as a combined solution. 

The cooper-ation of both partners is based on the commitment 

to two key objectives that will characterize the jointly 

produced solution: the first being „best in class“ in terms of 

function-ality, and the second calling for extremely userfriendly 

operation. In this way, the user is relieved of the need 

to pay attention to the details of FlexRay communications 

and is able to fully focus on the testing task at hand. 

Dipl.-Ing. (FH) Alexander Bayerl 

Alexander Bayerl studied communications 

engineering at the University of Applied 

Sciences in Esslingen. He entered the Robert 

Bosch GmbH in 1999. Alexander Bayerl is 

designing engineer in the LABCAR team and 

responsible for the specification and integration 

of the FlexRay component. 

Dipl.-Ing. Florian Wandling 

Florian Wandling studied Electrical Engineering 

at the Vienna University of Technology. He 

gained international experience in Dubai, Jakarta, 

and Manila during his studies. Florian 

Wandling is Product Manager for measurement, 

analysis, and testing tools at Elektrobit 

(EB) formerly DECOMSYS. 

Dr. Ulrich Wolters 

Dr. Ulrich Wolters studied Physics at the University 

of Bochum. He earned his doctorate 

with a thesis about „Non linear wave phenomena 

in ECR mirror discharges“ (plasma 

physics). Dr. Wolters is Strategic Marketing 

Manager for Test and Validation at ETAS 

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



FlexRay 

Becomes Daily Routine 

More and more engineers are nowadays confronted in their daily 

job with new challenges and tools required by the introduction of 

FlexRay as a new bus system for automotive applications. This article 

shows how engineers successfully meet the challenges of analyzing, 

simulating, and testing FlexRay ECUs and networks using 

CANoe.FlexRay from Vector. 

During the development of FlexRay ECUs and 

systems, engineers commonly encounter challenging 

tasks such as startup simulation, ECU 

tests and network simulation. This article describes how 

CANoe.FlexRay is already enabling FlexRay engineers 

to efficiently perform these tasks in a routine way. 

Startup Simulation 

A synchronized bus is a major requirement for a FlexRay 

communication. Before the application can communicate, 

the bus must be started. During this startup phase the bus 

is in an asynchronous mode until at least two ECUs have 

synchronized their FlexRay clocks and provide sync frames 

CANOE.FLEXRAY ENABLES ENGINEERS 

TO SOLVE BOTH ROUTINE AND 

CHALLENGING FLEXRAY TASKS 

so that other ECUs can integrate into the TDMA (Time Division 

Multiple Access) schedule. If the FlexRay communication 

of a single non-startup/sync ECU is being tested, 

then the analysis tool needs to be able to simulate a Flex- 

Ray bus that has already started. CANoe.FlexRay can generate 

two startup/sync frames in order to provide this type 

of startup of a FlexRay bus. The startup phase of a cluster 

can be observed using the asynchronous mode of Vector’s 

FlexRay interfaces VN3300 (PCI), VN3600 (USB) or VN7600 

(USB with CAN interfaces). It is possible for example to 

receive wakeup pattern, symbols, startup and normal frames 

before the cluster is in synchronous mode. The bus 

can also be analyzed in this mode without using a FIBEX


2007l11 


database. Only the baud rate is required in 

order to initialize the bus interface. To startup 

a sleeping cluster, wakeup pattern and 

symbols can be sent. The synchronous 

mode is the default mode, in which frames 

can be sent. The asynchronous and synchronous 

modes can also be combined so 

that the interface changes its mode automatically 

according to the clock synchronization 

state giving FlexRay engineers full 

analysis and simulation features at all 

times. 

ECU Test by Stimulation 

The easiest way of testing an ECU is to 

send frames interactively using CANoe’s FlexRay Frame 

Panel. Using this integrated panel a FlexRay frame’s payload 

(i.e. its signals) can be interactively modified during runtime. 

Signals for all bus systems can be modified via userdefined 

Control Panels. Using Signal Generators it is also 

possible to change a signal’s value according to predefined 

functions. For more advanced signal generation (e.g. arbitrary 

signal sequences or reactions to previous responses) 

the programming language CAPL should be used. Using 

the Test Feature Set of CANoe automated ECU tests can 

be defined, executed, and reported. 

ECU Test by Observation 

During the development of any real ECU it is crucial to guarantee 

that the ECU communicates in conformance with 

FlexRay’s schedule table. Especially for frames in the static 

segment a periodically time-triggered transmission is 

assumed. CANoe can directly test and visualize whether 

all expected frames (according to their Cycle Multiplexing) 

of a specific ECU (sender) are on the bus. This feature is 

implemented in CANoe.FlexRay as the FlexRay Cluster 

Monitor. It helps engineers to identify the following: 

■ Which nodes are online and sending? 

■ Are all specified frames sent by a specific node? 

■ Are the frames sent in all scheduled cycles? 

Figure 2:The Cluster Monitor for displaying the send conformity 

of FlexRay nodes and their messages 


Figure 1:The FlexRay Frame Panel makes it easy to interactively send 

FlexRay frames 


The Cluster Monitor can also be used in offline mode to 

analyze log files. More extensive tests can be implemented 

in the programming language CAPL (also for the offline 

analysis). 

ECU Test by Simulation 

In order to test the functional behavior of any real ECU, its 

environment must be simulated. The system or device 

under test is usually embedded into a (Hardware-in-the- 

Loop) simulation. A minimal remaining bus simulation 

generates input frames and reacts to output frames from 

the ECU under test. Optionally an environment model can 

be simulated, which generates sensor inputs and reacts to 

actuator outputs. A simple example would be a model of a 

discrete and interactive user panel. In more complex cases 

a quasi-continuous control algorithm (e.g. defined by Matlab/Simulink) 

may be executed under the control of CANoe. 

Due to the time-triggered communication according to a 

global FlexRay time, the algorithms for the simulated controllers 

and ECUs must be synchronized with the FlexRay 

schedule. The execution platform must therefore provide 

synchronization points, guarantee small latencies as well 

as constant and minimal jitters. This guarantees to provide 

timely correct data updates on the bus. For the environment 

or remaining bus simulation the execution platform 

must be deterministic. CANoe RT, along with its hardware 

extensions RT Box and RT Rack, provides such a high performance 

and deterministic platform. 

CANoe and CANoe RT and their hardware 

extensions can be seamlessly scaled to 

meet the desired performance as well as 

the number of required bus and I/O interfaces. 

For both CANoe and CANoe RT the 

same (simulation) models can be used. 

Cluster Simulation 

In the early design phases of a FlexRay 

system it is important to test whether the 

timings are correct and/or the performance 

of an ECU matches the communication 

schedule. In other words, to check whether 

all frames can be received and transmitted 

in the reserved time. The FlexRay 

engineer therefore typically creates a (par-



Figure 3: CANoe RT is a real-time capable and deterministic execution platform 

tial) remaining bus simulation by adding a FIBEX database 

to CANoe.FlexRay and by defining the nodes required for 

the system under test. The CANoe.FlexRay’s features 

allow the full bus load, which is generated by all ECUs of a 

cluster, to be simulated. The communication matrix and the 

FlexRay schedule in the FIBEX database are used to configure 

the simulation of all required ECUs. All frames are 

automatically sent on the bus with default values. With Vector’s 

interfaces the theoretical maximum frame throughput 

can be sent without running into resource problems (e.g. 

lack of send buffers). In this way all FlexRay ECUs can be 

simulated using only one tool and one bus interface. 

FlexRay offers direct support of network management and 

sleep/wakeup functionality. The bus transceivers of the 

Vector hardware interfaces can be switched to sleep mode 

in order to simulate a power off node. In this case only a 

wakeup pattern is received. Wakeup patterns can be sent 

in order to wake up a sleeping cluster. Using a special 

extension to CANoe.FlexRay, any simulated node can participate 

at the network management layer according to the 

AUTOSAR-NM protocol. 


Gateway Simulation 

Gateways are used to transfer messages/frames/signals 

between two or more buses. CAN/FlexRay-gateways are 

typically unavoidable when FlexRay is implemented for 

automobiles based on CAN. As a multi-bus tool for CAN, 

LIN, MOST, and FlexRay, CANoe is capable of both simulating 

and analyzing gateway applications. 

A virtual gateway can also be used to simulate errors in the 

communication between ECUs. The device under test is 

isolated from the real bus by a FlexRay-FlexRay-gateway 

that is simulated by CANoe. Errors can be integrated by 

manipulating signals that are sent by the real ECUs. Optionally 

the two FlexRay clusters can be synchronized. Synchronously 

running clusters guarantee minimal delays between 

the signal occurrences on both buses. 

Summary 

All these application scenarios occur during the routine 

work of engineers developing FlexRay products. 

CANoe.FlexRay is a powerful tool to help engineers in their 

everyday work when handling the new technical challenges 

of FlexRay buses. CANoe is the flagship of Vector’s 

comprehensive portfolio of tools and embedded software 

components which are ready for both current and future 

FlexRay applications. 

Gavin C. Rogers B.Eng. M.Sc. is Team 

Manager in the “Tools for Networks and 

Distributed Systems” product line. 

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

Development Engineer for the 

“Tools for Networks and Distributed 

Systems” product line.


2007l13 


FlexRay Protocol 

Implementation 

Analysis – 

The Story 

Finding implementation flaws was a 

really hard job until today. Now it 

will become common practice by stimulation 

with arbitrary FlexRay 

streams while simultaneously recording 

raw bus communication data. 

Background story 

FlexRay is becoming a new standard in automotive bus 

communication, most notably because of the early commitment 

from leading car manufacturers. Lots of manyears 

of electronic engineering was spent to develop all the 

specifications and to bring FlexRay on the road. FlexRay 

nevertheless is still a young and not yet a fully mature protocol 

with some ten years of experience. 

During our consulting and engineering with FlexRay some 

time ago, we observed sporadic frame errors in a communication 

setup with a beta version microcontroller with an 

integrated FlexRay controller. But what was the reason for 

these errors? According to our understanding, we ourselves 

probably had transmitted a misplaced frame at some 

special point in time, what this beta type controller inside 

the other node must have disliked a lot. Could it maybe 

even be a poor implementation of the FlexRay specification 

which has led to this behaviour? But how should we 

find this problem, if it’s really present? A lot of questions 

still to answer... 

Prerequisites 

First, we had to check the requirements for an analysing 

system to discover this kind of problem. We agreed that 

we must be able not only to receive but also to send frames 

simultaneously and synchronously with the FlexRay 

communication. Furthermore it must be possible to completely 

control the bus start-up behaviour as the problem 

seemed to be related with it. It would also be advantageous, 

if the system could be able to receive and store all the 

bus data, which means in our application the whole Flex- 

Ray raw bit stream for detailed debugging purposes later 

on. Most of today’s analyzer systems do rely on standard 

FlexRay communication controllers, where the protocol 

engine let pass only payload data and filters header information 

or symbols. 

Ertesis already had developed a basic FlexRay analyzing 

system, which we could extend and adapt to the actual 

needs. The analyzer was based on an FPGA development 

board. This embedded system was connected to a PC by 

Ethernet, where a simple control and display software in 

Java was running. The system already could sample Flex- 

Ray data, transfer it to the PC and show it in a table style 

window. Sending a simple FlexRay frame in an asynchronous 

way was possible, too. We decided to use this setup 

as the base for our further development (Figure 1). 

Improving the design 

Now as we had reviewed our existing hardware and software 

and identified all the requirements for the enhanced 

FlexRay test system, we started the upgrading. The heart 

of our system is an own FlexRay controller core IP, which



Figure 1: System setup for testing the faulty node 


we extensively upgraded to fulfil all the requirements mentioned 

before. A main issue was the start-up control. We 

wanted to completely manage the way the bus communication 

starts. All three start-up modes of the specification 

were implemented: coldstart node, following coldstart 

node and non-coldstart node. Beyond these modes, two 

arbitrary start-up modes have been integrated: force leading 

coldstart node and two-nodes coldstart, where the 

FlexRay controller core is able to start-up the bus communication 

on its own without any further coldstart nodes. 

Therefore we did not need to use any additional FlexRay 

controller like a MFR4300 for start-up. 

The implementation of offset and rate correction algorithms 

is essential for synchronously sending true FlexRay 

frames on the bus. They have been adapted and accelerated 

to be able to send frames already during the coldstart 

collision resolution phase, just where we assumed to locate 

the error. Correct sending has been 

verified with different low level parameter 

sets. 

The FlexRay controller not only samples 

all bus data like frames, glitches and even 

symbols, but also transfers this data stream 

to the PC to immediately display it 

and to store it on hard disk for later offline 

analysis. Simultaneously, the controller 

is recording high precision timestamps 

straight at the signal input of the 

Rx and RxEN pins. A main timestamp 

with 48-bit is stored for each frame or 

event. Due to the resolution of 12.5 ns 

this would result in a wrap around time 

span of about forty days. Incidentally, 

these high resolution recordings allow for 

measurement of the dynamic characteristics 

of FlexRay transceivers, for example 

idle detection times. Figure 2 shows an Rx delay between 

163 and 175 ns witch is in the proper range from 100 to 250 

ns as specified in the transceiver datasheet. Further important 

information of every frame, like main timestamp, TSS 

length in ns, frame length in bits, cycle number and frame 

ID is displayed. 

Finding the flaws 

Finally we finished our analyzer and synthesizer system for 

the planned debugging attempt. We connected the suspicious 

FlexRay node to our hardware and recorded its standalone 

communication first. As supposed, the node performed 

its coldstart attempts in slot 1 correctly. After the 

system was programmed as a following coldstart node, 

communication again started without any problems. Even 

with the system node being set up in two-nodes startup, 

the other node has integrated itself seamlessly. We knew 

that the problem probably must be located somewhere in 

the start-up phase, so we tried to disturb the coldstart of 

the node. Amongst different frames, we sent a synthesized 

frame in slot 3 in cycle 3, one cycle to early during the 

coldstart collision resolution phase of the node. 

We got it! The following frame coming from the system 

node, which was indeed completely correct, has been 

destroyed by the node (Figure 2). The disruption was caused 

by a CAS signal being sent during the frame transmission 

of the system node in slot 3, followed by a startup 

frame shortly later. This has drawn the bus level to a low 

signal. 

But why has it happened? We dug through the SDL charts 

of the FlexRay specification to find an answer for this faulty 

behaviour. We finally found a suspicious timer tStartup, 

which could be the culprit (Figure 3). If, for some reason, 

this timer is not correctly reset to its default value by 

reset(tStartup) after its expiration in the COLDSTART_ 

LISTEN state, it could be possible, that by the second entry 

into the COLDSTART_LISTEN state due to entering the 

ABORT_STARTUP state before, no waiting is performed, 

but immediately a new cold start attempt headed by a CAS 

symbol would be executed. 

Figure 2:Table view of the Java control application showing coldstart 

symbols and destroyed frame in cycle 3 

© automotive


2007l15 


Next task was to proof this theory. If the reason really 

is an incorrect or missing reset of the timer tStartup, 

there should be other paths and states leading to 

the same immediate second coldstart attempt. One 

of such other state is the COLDSTART_CONSISTEN- 

CY_CHECK state. If no other or an invalid startup 

frame is detected, the COLDSTART_ GAP is entered. 

If a valid header would be received during this gap, 

the ABORT_STARTUP state is entered. The following 

entry of the COLDSTART_ LISTEN state with already 

expired and not reset timer should then lead to an 

immediate coldstart attempt as well. We checked this 

by setting up a following coldstart transmission scheme, 

including a cycle 4 with a bit-flip to make it invalid 

followed by a correct cycle 5. 

Bingo! Node 2 destroyed our cycle 5 again with a CAS 

and a startup frame (Figure 4). With the FlexRay analyzer 

and synthesizer system, we could successfully 

prove that the timer tStartup is not correctly reset to 

its default value after expiration which effectively 

means an implementation flaw. qed. 

Figure 3: Entering COLDSTART_LISTEN state with expired timer 

tStartup leads to faulty behaviour 

Accomplishing further 

enhancements 

The development of Ertesis’ FlexRay system is still ongoing 

an recently, the company improved some very helpful 

features. One of them is an external signal output to trigger 

oscilloscopes on cycle starts, frame starts and other 

typical FlexRay events. With the new hardware trigger output, 

it is now possible to use existing oscilloscopes, rather 

then to buy a new and expensive one, only because of 




Figure 4: Faulty node sending his CAS and frame in slot 3 of system node, destroying 

bus communication 

being engaged in a FlexRay project. The second very helpful 

feature is the shift frame functionality. It is easily possible 

to shift a frame post or past its original action point in 

micro tick resolution, completely controlled by the use of 

the GUI. The action point could of course be shifted over 

the slot boundaries. 

Gearing up to new horizons 

All this functionality and features tends us to the decision 

to redesign the FlexRay Analyzer and Synthesizer system 

to be more powerful and that it could also be used as an 

Automotive Development Platform 

(Figure 5). It is based on the latest 

Cyclone FPGA family, surrounded 

by peripheral devices and physical 

interfaces. Special attention was 

given to the cost / performance 

ratio. A soft core CPU serves as 

main processor. Additional hardware 

e.g. an automotive optical 

Ethernet module can be connected 

through two Santa Cruz compliant 

expansion ports. The in-system 

reconfigurability of the platform is 

the key to easy and quick updates 

and even upgrades. 

© automotive Together with FlexRay modules 

based on the Freescale S12XF 

microcontroller, Ertesis is capable 

of providing a complete portfolio of hardware and software 

tools for easy and successful FlexRay deployment. 

Dr.-Ing. Gregor Burmberger 

has been involved with FlexRay for many 

years. His team and he are developing engineering 

tools for automotive electronics 

besides consulting the automotive industry. 

He is the founder of ERTESIS, Germany. 

Figure 5: Block diagram of the FlexRay Analyzer and Synthesizer and the Automotive 



2007l17 


ECU Tests for 

FlexRay Applications 

The projects planned for introducing FlexRay in future vehicle series require 

powerful test systems. These will allow the functional and electrical behavior 

of the FlexRay systems to be tested comprehensively at an early 

stage. One important testing method is restbus simulation, in which one or 

more electronic control units (ECUs) are validated in conjunction with complex 

simulation models. dSPACE offers a comprehensive range of solutions 

for this - solutions that are proven in practice and also undergoing constant 

further development. 

Test Methods for FlexRay Applications 

Restbus simulation is a proven method for testing a system 

consisting of networked ECUs. The available real ECUs are 

connected to a simulator via the FlexRay bus. The simulator 

uses substitute models for virtual representation of the 

missing bus nodes. Plant models, e.g., for vehicle dynamics 

or specific vehicle assemblies, and recorded measurement 

data can be simulated and used in conjunction with 

the substitute models in real time. The simulator sends the 

values output by the models to the real nodes, where they 

are available as input values. There are two forms of restbus 

simulation, static and dynamic: 

- Static restbus simulation involves a simple test structure 

in which the simulator generates synthetic messages as 

stimulus data and sends them to the real ECUs. These 

messages are independent of any simulated environment. 

- Dynamic restbus simulation gives the messages current 

values from detailed substitute and plant models. This generally 

requires powerful simulator hardware. 

A restbus simulation is derived from an existing communication 

matrix in FIBEX file format. Optimally, this step 

should be supported by development tools so that varying 

combinations of the ECUs under test can be put into operation 

flexibly. Partial automation of the restbus simulation



helps to reduce the configuration 

work associated with FlexRay, particularly 

for different integration stages 

of the ECU network. Finally, it is 

useful to express the substitute models 

in MATLAB/Simulink, i.e., 

using the same modeling language 

as is most widely used for plant and 

function models. 

The basic structure of the test systems 

used should be proven in 

practice. The systems must be scalable 

and extendable and also have 

sufficiently high processing power 

even for large restbus and hardware-in-the-loop 

(HIL) simulation. 

This necessitates tight time coupling 

between the simulator and the 

FlexRay bus, plus real-time-capable 

message generation and processing, 

including the manipulation of 

messages to simulate error cases. 

In addition, the simulators should 

have an identical operating concept 

for each extension phase, from function testing to component 

and subsystem testing, right through to final network 

testing of overall system integration. 

ECU Tests with the 

dSPACE Solution for FlexRay 

Test systems from dSPACE meet the above requirements. 

Over the past few years, these have been systematically 

prepared as a FlexRay solution and are now successfully in 

use under real-world conditions. 

Figure 2: User interface of the dSPACE FlexRay Configuration Tool 

Figure 1: Workflow with dSPACE’s FlexRay solution. 


Hardware Platforms for the Simulations 

All systems offered by dSPACE can be used as hardware 

platforms: 

- MicroAutoBox as the compact platform for function and 

component testing at a developer workstation. The Micro- 

AutoBox can be used with two FlexRay controllers, which 

enables it to start a FlexRay network. There is driver support 

for the Bosch E-Ray and also for the Freescale MFR 

4310 FlexRay Controller; the latter is available as a dSPACE 

DS4340 FlexRay Interface Module. 

- Numerous dSPACE Simulators Mid-Size 

have been shipped as component and 

subsystem testing stations. An interface 

board with slots for up to four FlexRay 

controllers can be installed in these simulators. 

This allows very flexible use scenarios 

within restbus simulation. 

- Networked dSPACE Simulators Full-Size 

are frequently used to set up network 

tests for overall system integration. The 

same interface concept is used for Flex- 

Ray here, in the form of a carrier board for 

pluggable FlexRay controller modules. 


Workflow for Configuring a 

Test System 

The workflow for configuring a test system 

is shown in Fig.1. In the dSPACE 

FlexRay Configuration Tool, the user selects 

from the data in a FIBEX file the communication 

elements that need to be available 

on the simulator (see Fig. 2). For 

example, these could be all frames that 

are sent by a virtual ECU represented on 

the simulator. Selecting these cases ge-


2007l19 


nerally requires only a few worksteps. As a result of the tool’s 

simple, direct user guidance, very little work is required 

to make modifications for new versions of the FIBEX file 

contents. The tool uses the selected configuration to generate 

code sections for communication routines and the 

parameters for the FlexRay controllers (called CHI code). 

These are then available for integration on the dSPACE 

hardware. 

In addition, communication data is extracted on the basis of 

the configuration and transferred to MATLAB?/Simulink, 

where they are used as parameters for FlexRay communication 

blocks from the RTI FlexRay Configuration Blockset 

(see Fig. 3). This procedure automatically creates a signalor 

frame-based block interface 

to which the test developer 

can add model-based 

test routines. These are then 

executed in a simulation on 

dSPACE hardware. The hardware 

is connected via the 

FlexRay interface to the 

FlexRay bus, and from there 

to the FlexRay ECUs, i.e., 

the units under test. 

Supplementary 

Tool Support 

The model’s interfaces to 

the FlexRay bus are configured 

for a dSPACE Simulator 

via the dSPACE FlexRay 

solution. A comprehensive 

range of tools for completely 

setting up and performing 

restbus simulation is also 

available from dSPACE. The 

following products are 

examples: 

- The environment and vehicle 

assembly models can be 

built with the Automotive Simulation 

Models (ASMs) 

and used together with the 

substitute models. 

- Interfaces to further bus 

systems such as CAN or LIN 

can be used in combination 

with FlexRay in the same 

model. Appropriate Real- 

Time Interface (RTI) blocks 

are available under MAT- 

LAB/Simulink for this. 

- The simulation results can 

be visualized via Control- 

Desk. 

- Test sequences can be 

automated with the AutomationDesk 

tool. 

Special Features 

The dSPACE solution for FlexRay was introduced as the second 

generation of FlexRay support tools in mid-2006. 

Since then it has been developed further in rapid product 

cycles, and Version 1.8 of the FlexRay Configuration Package 

will be available at the end of 2007. The major product 

features are summarized below. 

- Restbus simulation is configured according to ASAM 

MCD-2 FIBEX 2.0.1. As a supplementary feature, modeling 

communication data in the form of PDUs instead of Flex- 

Ray frames is also supported. This form of modeling is the 

answer to the AUTOSAR requirements for configuring a 

FlexRay communication stack. The contents of a FIBEX file



Failure and restart of a FlexRay controller 

Switching all event-based dynamic FlexRay frames on and off 

Switching all cyclic FlexRay frames on and off (old value or null frame is sent) 

Switching the sending of static frames on and off 

Switching the sending of a cyclic dynamic FlexRay frame on and off 

Manipulating bits in a frame via raw data access 

Switching over CRC algorithms during run time 

Sending and receiving invalid signals 

Simulating the failure of the synchronization service 

Simulating the failure of time-driven task execution with 

optional restart including correct synchronization 

Table 1: Error simulation procedures in the dSPACE FlexRay solution 

can be displayed in the FlexRay Configuration 

Tool. There are various sort and filter options. 

- The workflow for using the FlexRay Configuration 

Package aims at fast configuration of restbus 

simulation, right through to easy switching 

between the real and the simulated ECUs. 

- Static frames, cyclic and event-based dynamic 

frames, and dynamic frames with subframes 

are available in the simulation. 

- Communication tasks that pack physical signals 

into frames and place these in the FlexRay 

communication buffer (and also remove them 

from the buffer and unpack the signals) are created 

automatically. Further tasks in which the 

models are calculated can be created manually. 

Task execution is time-synchronous to the bus. 

- The communication buffer is optimally utilized. 

Start-up and synchronization behavior can be 

configured flexibly. 

- To supplement signal-based interfaces, the raw 

data of the FlexRay frames can also be accessed 

under MATLAB/Simulink. CRC calculations 

are easy to integrate. 

Recent versions of the FlexRay Configuration 

Package have introduced numerous extensions 

for error simulation. These relate to logical manipulation 

in FlexRay communication and are 

shown in Table 1. 

Summary and Outlook 

The previous sections showed the capabilities 

of dSPACE simulators in testing FlexRay ECUs. 

The basic prerequisite for this is proven simulation 

hardware and a powerful simulation environment 

based on MATLAB/Simulink. The documented 

features of the tools are already in 

use, helping to handle test tasks in FlexRay projects. 

Experience gained from practical use is 

reinvested in further development of the dSPA- 

CE solution 

Dipl.-Inform. Joachim Stroop 

is Senior Product Manager 

"System and Function Design 

Tools" at dSPACE GmbH. 

Dr.-Ing. Ralf Stolpe 

is Technical Project Manager 

"Distributed Systems / 

FlexRay" at dSPACE GmbH. 

Figure 3: Generated blocks of the RTI FlexRay Configuration Blockset 



2007l21 


Easy access to FlexRay 

FlexRay is getting more and more attention from the automotive industry. 

The number of persons who should or want to work with the relatively new 

bus technology is increasing quickly. Due to the high complexity of FlexRay 

it is even more important for rookies that the access to this subject is made 

as easy as possible. 

Amongst other factors the time that has to be 

invested in order to gain knowledge and experience 

in an unkown bus technology also 

depends on the developing platform to be used. Particularly 

with FlexRay a clearly structured starter concept 

is helpful for the acquisition of this technology and its 

different components. 

During the introduction into the FlexRay network technology 

and after a first theoretic approach the developing 

engineer soon wants to build up a sample network and 

thus test a first simple communication network. The determination 

of the network configuration requires an extensive 

planning period in which a detailed set of parameters 

has to be defined. For this, several software solutions are 

available in the market. However, they have not been developed 

particularly for beginners. This makes them difficult 

to operate and in addition to that they are also relatively 

expensive. Furthermore, the rookie needs hardware platforms 

which serve as FlexRay nodes. Although there are 

some microcontroller platforms with a FlexRay Controller 

available in the market, their handling is not really optimised 

for the requirements of beginners. 

This is why TZM has developed a special package called 

FlexDevel Kit which has been tailor-made for the particular 

needs of FlexRay rookies. The key element of this kit are 

two Microcontroller Eval Boards that work with a Freescale 

Power PC with integrated FlexRay Controller (MPC 

5567). The boards have the following interfaces: 

In addition to that there are different digital and analogue 

inputs and outputs (e.g. PWM). For the rookie it is important 

to implement his applications as comfortable and as fast as 

possible. Therefore, TZM provides extensive software: 

• GNU C-Compiler 

• Eclipse IDE 

• Nexus Debugger 

• Extensive 

programming 

library 

This turn-key kit gives the Flex- 

Ray rookie the possibility to 

find a quick way into the bus 

system FlexRay and to realize 

his industrial applications very 

soon. 

Apart from the FlexDevel Kit 

TZM also offers the FlexDevel 

Starter package which - in addition 

to the above mentioned 

components - also includes the 

Freeware analysing software 

FlexAlyzer basic and the Flex- 

Ray/PC-Interface FlexCard. A 2- 

day FlexRay training completes 

this comprehensive package 

• 2 FlexRay channels 

• 2 CAN high-speed bus 

connectors 

• 1 LIN 

• Sample programs for all 

available interfaces (even as 

source code which can be 

quickly modified by the user) 

• configuration software 

FlexConfig Demo 

Dipl.-Ing. (FH) Thorsten Kopp 

and Dipl.-Ing. (FH) Steffen 

Gugenhan are working as a 

Development Engineers in the 

division FlexRay & automotive 

Bussystems within TZ 

Mikroelektronik, Göppingen. 

• 1 RS 232 

• 2 SPI interfaces 

• 1 Ethernet 

interface



Testing CAN and 


Portable Gateway 

Tool for Testing CAN and 


Figure1:TTXConnexion test setup 


A user needs a number 

of powerful devices to 

effectively develop, 

integrate and test CAN 

and FlexRay networks. 

A dedicated tool from 

TTTech Automotive 

meets these requirements 

by providing a 

portable universal 

gateway tool for fast 

analysis. 

Since many years TTTech 

Automotive has acted as 

partner for FlexRay systems 

in the automotive industry. 

The company’s product range 

comprises standard software and 

hardware for system development, 

implementation, validation 

and testing as well as project and 

engineering support. The experiences 

in these fields led to the 

development of TTX-Connexion, a 

small, portable and autonomous 

test rig, which combines features 

for data manipulation, on-line viewing 

and logging for FlexRay and 

CAN networks in a single compact 

unit. 

Data manipulation for 

testing and validating 

systems 

To test FlexRay or CAN applications, 

it is necessary to modify messages 

on the bus. TTX-Connexion allows 

applying various data manipulation 

scenarios to simulate a variety of


2007l23 


environments without changing the software application 

itself. For configuring the FlexRay network parameters, signals 

and PDUs the user can employ network descriptions 

in FIBEX format. The CANdb description is supported for 

CAN-based networks. 

Gateway functionality as mediator 

between development phases 

TTX-Connexion is able to translate FIBEX communications 

schemes of various development stages. This gateway 

functionality translates signals in four different directions: 

FlexRay-to-FlexRay, FlexRay-to-CAN, CAN-to-FlexRay, and 

CAN-to-CAN. As a consequence, a newly developed ECU 

can be added to a network 

to handle additional features, 

even without modifying 

an existing control unit. 

Problems that might occur 

during the integration process 

comprise the connection 

of FlexRay control units 

from other projects or different 

states of readiness of 

the ECUs. 

TTX-Connexion supports 

such integration efforts by 

creating different sub-networks 

with their own Flex- 

Ray schedules. The device 

links networks and translates 

the messages of one 

FlexRay network into another 

FlexRay network. As a 

result, control units from different 

integration phases 

are formed into a single network. 

Data logging 

and on-line data 

viewing in real 

time 

TTX-Connexion allows the 

operator to filter and log all 

measured test data on a 

compact flash card. This 

device supports intelligent 

logging, which ensures that 

data are recorded only if 

needed for later analysis. 

The selective filtering of 

information reduces memory 

and time utilization. 

An enclosed viewing tool 

enables the monitoring of 

manipulations and their 

effects as well as analysis of 

the bus communication in 

real time. 

TTTech Automotive´s TTX-Connexion represents an ideal 

solution for analysis and system integration. It can be used 

to test applications running on FlexRay and CAN networks 

through all work stages, from early prototyping to start of 

production. The company’s wide range of products and 

solutions in the field of FlexRay are for example deployed 

in the optimization process of the data communication in 

the next generation of the Audi A8.



FlexRay in AUTOSAR 

FlexRay and AUTOSAR are the major challenges in automotive electronics 

over recent years. Both standards have reached a certain maturity and are 

now facing their introduction in mass produced vehicles. Fujitsu Microelectronics 

Europe GmbH, as a member of both consortiums, offers solutions 

for both these standards. 

Since the end of 2005 a stand-alone FlexRay Communication 

Controller (CC) (MB88121) has been 

available while a 32-bit MCU (MB91F465X) with 

an embedded FlexRay interface followed in early 2007. 

Additionally, AUTOSAR packages are available for the 32 

bit MB91460 family, which have already been shipped to 

leading customers. 

FlexRay will become an ‘established’ network in the automotive 

area, as several car manufactures are using the bus 

system in their new series. AUTOSAR version 2.1 was released 

in the first half of 2007 and next releases are planned; 

V3.0 before the end of 2007 and V4.0 towards the end of 

2009. This underlines its importance and long-term scope 

for upcoming designs for future vehicle platforms. At this 

time many developers are raising questions such as: ‘How 

does the AUTOSAR concept work when designing for mass 

production?’, or, ‘How mature is the AUTOSAR toolset and 

will it satisfy designers’ requirements?’, which this article 

attempts to answer. 

The AUTOSAR concept provides a standardised software 

platform. The design method of AUTOSAR systems follows 

a top-down concept. The complete system is specified by 

connecting Application Software Components (SW-C) to a 

virtual bus. The next step is to break down to ECU level. The 

SW-C are distributed to the different ECUs and the virtual 

bus is replaced by the Run-Time Environment (RTE). At ECU 

level the AUTOSAR software needs to be configured to the 

local ECU’s requirements. For this purpose all SW C (Application 

tasks) are connected to the RTE via their SW-C interfaces 

and all Basic Software modules (BSW) are added to 

the design. Both type of modules need to be configured by 

a configuration tool like tresos from Elektrobit. For example, 

hardware (HW) drivers need to be set up; the number of I/O 

ports specified and direction of ADC channels defined, as 

well as configuring communication channels like LIN, CAN, 

FlexRay and others. Additionally, RTE, which is the interface 

between the Application Layer and all BSW, needs configuring. 

It is a static configuration that requires a new configuration 

of both ECUs when moving a SW-C from one 

ECU to another. However with the right tool support this 

task happens automatically. 

The AUTOSAR software is structured in a layer concept. 

Figure 1 illustrates the AUTOSAR architecture and its layers 

as: Application layer, Run-time Environment (RTE), Service


2007l25 


layer, ECU abstraction layer and MCU abstraction layer. The 

Application Layer comprises all functionality of the Application 

Software and consists of several Software Components 

(SW-C). The AUTOSAR Run-time Environment (RTE) 

is the Application Abstraction Layer, which acts as an interface 

between the application and the AUTOSAR Basic Software. 

The Basic Software is categorised into three groups; 

Service layer, ECU layer and Microcontroller Abstraction 

layer. The task of the service layer is to provide the basic 

function to the application and basic modules. Operating 

system, memory, and communication services belong to 

this category. The ECU abstraction layer interfaces with the 

drivers of the Microcontroller Abstraction Layer, while the 

Microcontroller Application Layer comprises the driver and 

software modules, which have direct access to the MCU’s 

internal resources. These two layers ensure 

that the application remains independent of 

ECU and MCU. 

The connection to the FlexRay bus system is 

the function of the FlexRay Communication 

Stack (yellow highlighted in figure 1). Parts of 

this communication service are located in a 

common module. These common parts are 

modules such as AUTOSAR COM, Diagnostic 

Com Manager (DCM), Generic NM, PDU (Protocol 

Data Unit) Router and IPDU Multiplexer. 

Each of these modules needs to be configured 

to the ECU demands. Looking at the pure Flex- 

Ray element, there is a FlexRay Transport Protocol 

Module, FlexRay Network management 

(NM) and XCP Transport protocol on FlexRay at 

the Communication service layer. The FlexRay 

NM takes care of the FlexRay-specific network 

management issues that are not available in the generic NM 

modules or where adaptation of generic NM signals becomes 

necessary. At the ECU Abstraction layer the FlexRayspecific 

element is the FlexRay interface module and external 

FlexRay device drivers (e.g. for FlexRay transceiver or 

external/internal FlexRay CC). This FlexRay Interface module 

routes the signals from the PDU Router to the dedicated 

driver, e.g. FlexRay driver or FlexRay transceiver driver. The 

FlexRay driver for an integrated FlexRay CC is part of the 

MCU abstraction layer. This driver module accesses the 

internal registers of the FlexRay CC, and again all these 

modules need configuration. All other HW modules such as 

CAN, memory driver, etc., also need to be configured, 

which leads to a large number of configuration settings. 

Nowadays the FIBEX format is used to keep track for the 

FlexRay Bus settings. The majority of them refer to the initialisation 

of the FlexRay driver. But tresos by Elektrobit provides 

configuration parameters for the other layers too. For 

example, the assignment of all signals throughout all layers 

can be defined with that tool, which has been fully adapted 

to the MB19460 series from Fujitsu. The software development 

can be performed in parallel to the basic software configuration 

because by definition, the application layer is 

independent from the basic software. When all basic software 

configurations are completed, a FlexRay signal flow 

throughout the modules should operate as follows: 

Figure 1: AUTOSAR architecture 

The example assumes that one SW-C wishes to transfer a 

signal to another SW-C. The transmitting SW-C does not 

know if its transfer is to a local module or to a module on 

another ECU. Therefore an initial request for a signal transmission 

is passed to RTE via the SW-C port. During configuration 

of RTE this SW-C port was assigned to AUTOSAR 

COM, so the RTE passes this signal to the AUTOSAR COM. 

Here the signal is submitted to the Protocol Data Unit Router 

(PDU) and new signal definitions are applied to meet low 

level hardware requirements. The PDU router passes the 

signal to the dedicated communication interface, according 

to the signal definition in the PDU Router. In this case the 

signal is mapped to the FlexRay communication driver, so 

the signal is passed to the FlexRay interface, which passes 

it again to the FlexRay driver according to the signal ID definition. 

The FlexRay driver itself will now write the signal data 

to the FlexRay CC message buffer and set Tx request. The 

signal data is transmitted via the FlexRay bus and received 

by the corresponding EC. At the receiver side, any SW-C 

can issue a signal read request to RTE. This request is passed 

through all modules – RTE, COM, PDU, and FlexRay 

interface – from where the signal data is retrieved. The Flex- 

Ray driver will read the message buffer and pass the value 

back to the upper layer. 

All these functions can be used on 

Fujitsu’s 32-bit MCU series 

MB91460. Together with a state-ofthe-art 

AUTOSAR configuration tool, 

tresos, the system designer has a 

powerful solution at its side. Today 

Fujitsu offers an off-the-shelf AUTO- 

SAR package for the MB91460 

series based on revision 2.0. Future 

upgrades to 2.1 and beyond are 

planned. Complemented by Fujitsu- 

’s starter kits, e.g MB91465X 

100PMC featuring a 100-pin Flex- 

Ray-MCU, anyone can discover all of 

the AUTOSAR-based FlexRay software 

capabilities of Fujitsu’s 32-bit 

platforms 


Dipl. Ing. Matthias Steeg 

is application engineer at 

Fujitsu Microelectronics 

Europe, in the Automotive 

Business Unit. Since 2004 

he concentrates on Flex- 

Ray and became an expert 

for customer support in 

this application field."



Body and gateway microcontroller 


FlexRay has become a standard interface for NEC Electronics. Since we joined 

the FlexRay consortium in 2003, we have launched two microcontrollers 

(V850E/CAG4-M, V850E/PHO3) with embedded FlexRay on the market 

and we have performed many application and simulation tests. From 2008 

onwards, our FlexRay MCUs will be found in OEM series FlexRay networks. 

The V850E/CAG4-M is a new member of NEC’s 

powerful 32-bit V850 RISC microcontroller family 

with embedded FlexRay communication 

controller based on the Bosch E- 

Ray IP Module R1.0. With 8 Kbytes 

of FlexRay message RAM, the 

V805E/CAG4-M is ready for applications 

with huge amounts of TX 

and RX data. 

Offering high performance, large memory 

and fully-fledged communication 

interfaces, it is optimized for 

automotive body applications like 

gateways, providing control of up to 

6 CAN as standard interfaces. Easy Fig. 1: V850E/ 

access to the MOST world is provi- 

PHO3 package 

ded by the V850E/CAG4-M with its embedded MediaLB 

interface for very high data throughput, especially for 

asynchronous data transfer. The new multi- 

LIN master macro can connect up to 

6 LIN channels very efficiently 

and reduce the CPU load to a minimum. 

The V850E/CAG4-M also 

has a 16-bit parallel external bus 

interface for connecting to external 

components like flash or RAM. 

The timer structure is suitable for 

body applications offering multiple 

input capture and PWM output channels as 

well as a dedicated motor control. With realtime 

clock and power-saving mode support, the 

device is right for many car body applications.


2007l27 

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

The device’s internal window watchdog, 

parity on RAM, ECC on flash 

(single error correction, double error 

detection), CRC unit and FPU all support 

safety-relevant applications. 

Chassis MCU: 

V850E/PHO3 

The V850E/PHO3 is NEC Electronics’ 

first MCU with embedded FlexRay. It 

is optimized for inverter control applications 

requiring control of up to two 

3-phase brushless DC motors simultaneously, 

for example in electronic 

power steering, braking or damping. 

Equipped with an embedded FlexRay 

communication interface and 2 CAN 

interfaces, the V850E/PHO3 is designed 

for advanced network architectures 

and future x-by-wire applications. 

Its on-chip safety features, such as CRC, ECC on 

flash and RAM, meet the highest safety requirements and 

support applications targeting IEC61508 SIL3 certification. 

Other V850 microcontrollers with embedded FlexRay are 

on our product roadmap and will be available soon to cover 

automotive applications like chassis, safety, body, gateway 

and audio. 

Fig. 2: AUTOSAR software architecture 

FlexRay solutions. 


All our FlexRay microcontrollers offer fastest access to the 

FlexRay communication controller via a 32-bit non-multiplexed 

synchronous interface with minimal CPU interaction. 

Each MCU also includes a dedicated PLL that supplies the 

FlexRay controller with a separate clock and guarantees highest 

FlexRay timing accuracy. 

Nice to meet you: 

FlexRay Product Day 

November 29th, 2007 

Fellbach nearby Stuttgart 

Booth No. 24 

Control the FlexRay bus with reliable 

tools. 

Modular software and hardware design 

permit the user rapid access to FlexRay and 

other bus systems. FlexRay communication 

is easily built up with two integrated startup 

nodes and import of FIBEX data. The new 

high performance vehicle communication 

interface HSX with PowerPC-Core allows for 

high data throughput and time critical 

execution of FlexRay and other multi instance 

bus protocols. Its usage as diagnostic tester 

or for active and passive rest bus simulation 

or as gateway between CAN and FlexRay 

offers excellent flexibility to the developer. 

samtec is a supplier of cutting-edge software 

and hardware in the field of vehicle 

communication technology, with more than 

20 years of experience. We are 

glad to inform you personally 

under +49 711 45 80 90 or 

simply log onto www.samtec.de. 

Smart. Sensitive. Supporting.



FEATURES: 

V850E/CAG4-M 

V850E/PHO3 

· V850E @ 80 MHz with FPU @ 128 MHz with FPU 

· 512 Kbytes 

· 1 Mbytes flash/60 

flash/60 Kbytes RAM Kbytes RAM 

· FlexRay (2-channel, 

· FlexRay (2-channel, 

v2.1, 8 Kbytes RAM) 

v2.1, 6 Kbytes RAM) 

· 2 x CAN 

· 3-wire MediaLB interface 

(32 + 32 message buffer) 

· 6 x CAN (6 x 48 message 

· 2 x CSI, 2 x buffered CSI, 

buffer; mirror mode) 

3 x LIN UART 

· 4 x CSI, 6 x LIN-UART · 2 x ADC (10+10-channel), 

(+MLM), I2C 

10-bit, 2 µs 

· ADC: 10-channel, 10-bit, 2 µs · 2 x real-time pulse unit 

·144 QFP package 

for motor control 

· 357 PBGA package 

Fig. 3: V850E/PHO3 

FlexRay conformance test 

Because FlexRay is a complex protocol, it’s essential that 

each controller behaves as described in the FlexRay specification. 

This prompted the FlexRay consortium to specify 

a conformance test that was then implemented by TUEV 

Nord. Based on 275 test cases, the test checks the correct 

functional behaviour of the embedded FlexRay communication 

controller as described in the current FlexRay v2.1 

specification. The FlexRay conformance test is a prerequisite 

for interoperability and faultless communication between 

FlexRay communication controllers. 

As the world’s first microcontroller with embedded FlexRay, 

the V850E/PHO3 passed the FlexRay CT at TUEV NORD b/o 

2007. This is documented by a conformance test certificate 

that is obligatory for every microcontroller implemented in 

a FlexRay cluster for use in series production cars. 

In addition to the conformance test, NEC Electronics has 

conducted an extensive in-house evaluation of the FlexRay 

communication controller, using both simulation runs and 

actual applications. 

NEC Electronics is also an active member of the JasPar 

consortium that conducts several stress and interoperability 

tests capable of proving 

that our V850 

MCU also runs correctly 

in an inhomogeneous 

FlexRay network. 

FlexRay evaluation 

board and AUTOSAR 

starter kit 

NEC Electronics joined the AUTOSAR partnership 

as a premium member in March 2004. The main 

focus within the AUTOSAR partnership is on software modules 

that are either very close to, or interact directly, with 

MCU hardware. NEC Electronics’ microcontroller abstraction 

layer (MCAL) software contains all AUTOSAR device 

driver and interface modules. To match the exceptional quality 

standards of the hardware, the MCAL software was developed 

using best-in-class software processes certified to 

CMMI Level 5 and SPICE Level 3. Several software companies, 

like Vector Informatics and Elektrobit, already offer 

a complete AUTOSAR stack (from operating system 

through memory management to communication) for the 

V850E/PHO3 based on our MCAL. 

To facilitate the introduction of AUTOSAR on the market, 

NEC Electronics developed an AUTOSAR starter kit that includes 

both hardware and software. The hardware is an evaluation 

board with a V850E/PHO3 MCU and several interfaces. 

The software contains the complete AUTOSAR 

MCAL including the FlexRay driver/interface software and 

a configuration tool. 

The AUTOSAR starter kit is ideal for software engineers 

who would like to start working with AUTOSAR, and is the 

perfect way to create first FlexRay applications. It includes: 

Hardware: 

■ PCB with V850E/PHO3 

■ Interfaces for FlexRay, CAN, CSI, UART 

■ Interface for an external FPGA 

■ Motor control interface 

■ Display and LEDs for signaling test results 

Software: 

■ AUTOSAR MCAL software 

■ AUTOSAR configuration tool 

■ Demo application 

■ Documentatio 

starter kit board 

Dipl-Ing Holger Schmerling studied 

electrical engineering at the Cologne 

University of Applied Sciences specializing 

in communication systems. For 

the past 5 years he has worked as an 

application engineer on FlexRay, 

TTCAN and AUTOSAR in the NEC Electronics 

Automotive Business Unit in 

Düsseldorf.


2007l29 


FlexRay Controller - 





communications controller and 

one integrated into its high end 

32-bit microcontroller family 

Automotive system designers require a 

combination of performance, flexibility, 

cost effectiveness, scalability and safety 

that is sometimes hard to reach. A fully integrated 

solution can be cost effective but requires 

a whole new system design. 

While designs have more pressure on space, 

using a discrete solution can take more space but 

provides the potential to upgrade the system easily. 

This also allows developer to use a range of different 

processors, both within a family of devices, 

re-using the same software, but also across different 

families for different applications, from cars to 

high end motor cycles. 

A key example of this comes from using the Flex- 

Ray communications protocol. Version 2.1 of the 

specification has been available for several years 

now, but the devices that support the new standard 

have taken time to come to the market. One 

of the first was the CIC310 stand alone FlexRay 

communication controller, which has been qualified 

in many designs, but now this same design 

has been integrated into the TC1797 TriCore 32-bit 

controller (Figure 1). This allows system integrators 

to build fully FlexRay v2.1 compliant in-vehicle 

networks for powertrain, chassis and body applications. 

The FlexRay controller core is based on the widely 

used E-RAY design from system supplier Bosch 

and is integrated into the TC1797, part of the AUDO 

FUTURE microcontroller family. This family uses 

the high performance 32-bit TriCore processor core that 

combines microcontroller functions with digital signal processing 

and the industry’s highest density flash memory. 

The family includes a wide range of peripherals such as a 

fast ADC, DMA memory engine and several serial interfaces 

and external bus Interfaces. Most of the family also has 

an additional 32-bit Peripheral Control Processor (PCP) on 

board that offloads the main CPU by running the low-level 

drivers for the integrated peripherals. 

The previous TC1796 recently achieved a score of 100 Automark 

in the certified EEMBC Benchmark (http:// 

www.eembc.org/) – the highest score for an automotive 

qualified microcontroller in this frequency range. The 

TC1797 adds another 30% system performance with its Tri- 

Core operating at 180 MHz. 

This level of performance and integration is aimed at high 

end engine control units (ECUs) to handle the complex 

algorithms for emission control and FlexRay is mandatory 

in current and future designs of these systems (Figure 2). 

Discrete: The flexible way 

At the same time there can be advantages from using a 

discrete controller. The CIC310 is a standalone FlexRay 

V2.1 Protocol Controller based on the same Bosch IP and



Figure 1:The TC1797 uses a new high performance 32- 

bit TriCore CPU that combines microcontroller functions 

with digital signal processing and the industry’s highest 

density flash memory. 


has already passed the mandatory FlexRay Conformance 

Test. It is partnered with a microcontroller or microprocessor 

via a standard interface and allows designers to provide 

FlexRay as an optional feature that can be easily integrated 

into an existing hardware and software design. In 

this case, the footprint for the CIC310 and the according 

FlexRay transceiver will be available on printed circuit board 

but the devices will be only mounted if needed, and this 

also provides an upgrade path for existing systems. 

Figure 2:The TC1797 microcontroller is optimized for engine management 

systems and transmission. In engine management, the TriCore provides lower fuel 

consumption and improved emissions.With a number off build-in safety features 

like a Memory Protection Unit (MPU) the TriCore is also a fit for safety critical 

application in chassis control area like high-end sensor clusters and suspension. 

The controller supports both FlexRay communication channels 

with a maximum bandwidth of 10 Mbit/s each and provides 

8.25 KBytes of configurable message RAM for storing 

up to 128 messages. The redundancy of the two independent 

communication channels, along with the FlexRay 

time-triggered communication schemes and high bandwidth 

are key for safety critical automotive applications. 

Low power is also a key feature of the CIC310. Manufactured 

in a 130 nm process technology, the core consumes 

30 mA to 50 mA. 

To support designers, a number of hardware features are 

implemented. Eight independent DMA channels offer an 

efficient transfer mode without using the host CPU. Several 

interrupt lines give full control of the CIC Channel Host 

Interface (CHI) and the E-RAY communication controller, 

and this provides three different interfaces (Figure 3): 

A low pin count SPI (Serial Peripheral Interface) interface 

supporting up to 20 MBaud Bandwidth 

A configurable 8/16-bit wide bus parallel interface including 

a 13 Bit address bus (with address extension mechanism 

to 32-bit) supporting up to 10 MByte/sec bandwidth 

A high speed serial MLI (Micro Link Interface) supporting 

up to 40 MBaud 

This flexible channel host interface means the CIC310 can 

be used with almost any microcontroller or microprocessor 

architecture available in the market. 

The new TC1767 and TC1736 TriCore controllers do not have 

integrated FlexRay and provide a path for more cost optimised 

designs from the TC1797 using the same software. Both 

integrate the same microcontroller core as TC1797, the same 

built-in safety features like a Memory Protection 

Unit (MPU) and a software-compatible 

peripheral set. In addition to powertrain applications, 

the TC1767 and TC1736 can also be 

used in safety critical application in chassis 

control area like high-end sensor clusters and 

suspension. 

To connect the TriCore to the CIC310, all three 

interface options available can be used. The 

most efficient interface is using the Micro 

Link Interface (MLI) as this provides synchronous 

high-speed serial connection for automatic 

data transfer/request transaction between 

a local and a remote controller. It also 

supports transparent read/write access with 

a low pin count. 

For the connection between the processor 

and the Companion IC only eight pins are 

necessary - four each for transmit and receive. 

Further pins are available for additional 

interrupt lines to monitor both the ERAY Controller 

and the CIC310. 

As the TriCore internal bus structure supports 

the DMA capability of the CIC310 via MLI 

interface, the FlexRay communication is supported 

with minimum performance requirement 

from the main TriCore CPU. Other internal 

DMA operations can also be offloaded to 

the on-chip 32-bit peripheral controller. 



2007l31 


Figure 3: Infineon’s Channel Host Interface (CHI) Concept for the 

CIC310 supports 3 different options: a standard parallel interface, 

a Serial Peripheral Interface (SPI) and a High Speed Serial Micro 

Link Interface (MLI) 


Well supported 

The discrete controller is not just applicable to the TriCore 

family. The latest XC2200, XC2300 and XC2700 families of 

controllers are based on the Infineon’s C166S V2 microcontroller 

architecture and can all make use of the discrete 

FlexRay controller. 

The XC2200 is designed for body applications like Body 

Central Module, Central Gateway and air-conditioning with 

power consumption in standby down to 50 uA as well as 

extended communication capabilities. The XC2300 family 

covers applications in the safety critical area like airbag and 

Electronic Power Steering (EPS) by adding Error Correction 

Code (ECC) on all memories, memory protection, a CRC 

(Cyclic Redundancy Check) and redundant analog-digital 

converters, and supports systems to be certified in 

IEC61508 level SIL3. The XC2700 32-bit microcontrollers 

are optimised for Engine Management and allow system 

makers to build cost-effective electronic engine control in 

motorcycles around the world to meet upcoming emission 

standards. 

Interfacing the XC2200, XC2300 and XC2700 to the CIC310 

can be either through the standard 8- /16-bit parallel bus 

interface or through one of the incorporated USIC’s (Universal 

Serial Interfaces). These support the fast SPI standard, 

running a bandwidth of up to 20 Mbit per second between 

the CIC310 and the microcontroller. In applications 

with critical latency requirements, the parallel interface is 

the recommended solution as it supports a speed of up to 

10 MByte per second with very low latency impact. 

But implementation is also an important issue for designers, 

so AUTOSAR software drivers for the CIC310 are 

available and have already been proven by the AUTOSAR 

Validator project. At the same time, the TriCore family as 

well as the XC2200, XC2300 and XC2700 families are supported 

by a full suite of development tools including evaluation 

boards, debuggers, compilers and documentation. 

Automotive equipment makers are already using FlexRay 

Kai Konrad (l.) is Product Marketing Manager 

for Microcontrollers Automotive at Infineon 

Technologies, and Holger Huber (r.) is Product 

Marketing Manager for Microcontrollers 

Automotive at Infineon Technologies 

in series production, and broad introduction is planned 

already in 2009. This means a wide range of 

different solutions will be required by the equipment 

makers, all based around FlexRay as the 

communications controller. 

Having both integrated, tightly coupled implementations 

such as the TC1797 and the discrete 

CIC310 allows the system design to select the right processor 

core for the application and still easily provide Flex- 

Ray communications. The discrete approach also provides 

a simple upgrade path for today’s designs to become Flex- 

Ray-enabled. 

FlexPower 

for your solutions 

FlexConfig Developer 

Import and Export of FIBEX 1.2 and FIBEX 2.0 

State-of-the-art graphical editors and user assistance 

 

 

 

1-year free support and updates 

Robert-Bosch-Str. 6 

Fon: +49 7161 5023-0 

www.tzm.de 

intuitive and 

 

TZ Mikroelektronik 

 

tool for FlexRay with 

FIBEX-support. 

New 

 

 

D-73037 Göppingen 

Fax: +49 7161 5023-444 

sales@tzm.de 

A company of Steinbeis GmbH & Co. KG für Technologietransfer



C&S: Tested 

Products online 

To support engineers developing 

new network components, the C&S 

group provides a list of tested products 

on the internet. The list is still 

not complete, but C&S is working on 

it! The listed CAN and LIN devices 

have been tested at C&S - like many 

others, which they are not allowed 

to publish.. FlexRay is in the pipeline. 

■ http://www.cs-group.de 

Kyocera: 

Crystal Unit for 

Engine Control 

Circuits 

For automotive applications Kyocera 

introduces the surface mount type 

crystal unit CX3225SA. With an operating 

temperature range of ?40 to 

+150 °C, a good rust prevention performance 

and the small and low profile 

(3.2?2.5?0.8 mm) it is dedicated 

to engine control applications. The 

usage of a ceramic package is resulting 

in high reliability. The frequency 

range is from 12 MHz to 54 MHz 

with a frequency tolerance of ±50 

x10-6 at 25 °C. The devices are 

reflow compatible with improved 

solderability. 

■ http://global.kyocera.com/ 

application/automotive/product/ 

compo/crystal.html 

PRODUCTS 

Ixxat: FlexRay/ 

CAN platform 

The FlexRay CCM from Ixxat Automation 

is a FlexRay/CAN platform 

for both PC-based and stand-alone 

applications. As an open PC interface, 

it is measuring hardware for 

comprehensive analysis and simulation 

tasks for FlexRay and CAN 

networks. An exact local time enables 

synchronous logging of Flex- 

Ray and CAN messages. The Flex- 

Ray analysis is carried 

out both via 

the FlexRay protocol 

module and via 

an asynchronous bit 

stream analysis, so 

that both the start-up 

behavior and specific 

errors on the FlexRay 

bus can be detected. 

The micro-controller 

system (MPC 866, 

130 MHz) allows realtime-critical 

tasks to 

be performed directly on the hardware 

in the form of add-on software 

modules. In this way, realtime 

rest bus simulations, protocol 

implementations or emulation 

functions can be implemented. The 

interface is connected to FlexRay 

via the current version of the Flex- 

Ray chip (freescale MFR 4300). 

Upgrading to new chip generations 

is carried out with plug-in modules. 

With the new dual chip extension, 

two FlexRay cold starters can be 

implemented with one hardware 

platform. Thus the device can also 

start FlexRay networks containing 

only integration nodes. The Flex- 

Ray CCM can be used as an autonomous 

device, which enables use 

as a FlexRay/CAN gateway, for 

example. The interface communicates 

via Fast Ethernet TCP/IP 

(10/100Mbit/s) and is designed for 

processing of 100 % bus load on all 

bus systems. 

In addition to two 10 Mbit/s Flex- 

Ray interfaces, the interface has 

two CAN interfaces (ISO/IS 11898- 

2 high-speed CAN und ISO/IS 

11898-3 low-speed CAN). 

To control external hardware components, 

the interface has four trigger 

outputs, which can be controlled 

via FlexRay messages or by the 

FlexRay cycle. In addition, two trigger 

inputs are available. 

■ http://www.ixxat.com

SPECIAL EDITION FLEXRAY · PRODUCTSl AUTOMOTIVE 

2007l33 


Agilent: 

Vehicle Protocol Tester 

For vehicle topologies consisting of CAN and LIN networks, 

Agilent’s Vehicle Protocol Tester VPT501 is a 

debugging and analysis tool for complex communication 

relations. The VPT501 has a robust housing that is designed 

for the usage in vehicles, with CAN (2x) and LIN 

(2x) and the digital input/output interfaces. The following 

key features are packed into the box: 

• various and extensive data analysis of network communication 

• innovative and automated timing analysis capabilities 

• simple configurable rest-bus emulation without programming 

expenditure 

• an integrated data logger for stand-alone mode 

The timing analysis capabilities make it possible to identify 

and analyze communication problems in the network 

faster, simpler and more effectively. During the recording 

of the communication, the timing checker determines 

the minimum, maximum and average follow-up time for 

all frames in connected CAN and LIN networks automated 

and in real time. 

We work hand 

in glove with you 

Infotainment 

The VPT501 supervises time borders that can be configured 

by the user and indicates each violation online. 

This enables fastest identification of the source of error 

and analysis of the time performance in case of an error. 

The signal chain analysis allows a simple, automated 

timing analysis of data flow beyond interfaces and networks. 

Thereby for example gateway latencies, response 

time, physical -to-protocol conversion, protocol-tophysical 

conversion or synchronized event timing can be 

determined in a very simple way. 

■ http://www.home.agilent.com 

Testing 

Technical innovation guarantees successful business 

We keep you on the move. As a comprehensive provider of customized IT 

services, we are a reliable and competent partner for the entire automotive 

and transport industry. Based on profound industry knowledge and a strong 

sense for trends, we develop innovative solutions for today and tomorrow. 

Get more information: www.tietoenator.de 

Safety 

AUTOSAR


34lA UTOMOTIVE 2007 

Elmos will deliver 

FlexRay chips to BMW 

Elmos Semiconductor AG 

announced to be a supplier of 

integrated circuits of the new 

high-speed bus standard Flex- 

Ray at BMW. Delivery is expected 

to start mid-2008 and will 

include a star coupler for Flex- 

Ray systems to begin with. The 

newly developed integrated circuit 

replaces four conventional 

single transceivers. 

The FlexRay IC E910.56 is a 

fourfold star coupler, which can 

be roused via network and has 

its own SPI diagnoses interface 

at its disposal. Thus the IC enables 

a comprehensive functionality 

for diagnoses coupled 

with appropriate error detection 

and treatment. The E910.56 

allows for a low-priced and 

space-saving intelligent FlexRay 

network management. Due to 

optimized EMC behaviour the 

star coupler handles high data 

streams of up to 10 Mbit/s and 

offers real-time networking. 

■ http://www.elmos.de 

Samtec: Vehicle 

Communication Interface 

Samtec’s HSX is a modular built VCI (Vehicle Communication 

Interface) with a 32 Bit PowerPC-Core (350 MHz). Due 

to its multibus design diagnostic tasks can be simultaneously 

executed on several bus systems like LIN, SAE J1850 

and SAE J1708. Up to 6 Full CAN interfaces and 4 K-Line 

interfaces (with up to 500 kBaud in K-Line/RS485 mode) 

are available. Very high data throughput and precise time 

synchronization enable the analysis of control unit 

networks with high speed buses like FlexRay. The 

FlexRay interface is capable of 2x 10 MBit/s. 

Further implementation areas include rest 

bus simulation, remote vehicle diagnostics 

via wLAN or usage as gateway. Furthermore 

the HSX interface can be integrated 

in tool chains that are based on the new 

MVCI standards as per the ISO 22900 norms. 

Hence the interface can be used not only with 

samtec software but also with other diagnostic applications 

that conform to the norms. 

PRODUCTS 

Xilinx 

LogiCORE 

Xilinx LogiCORE FlexRay controller 

implements the FlexRay communication 

protocol as defined in the FlexRay 

Protocol Specification v2.1 Rev A. The 

FlexRay controller implementation 

supports a single communication 

channel with configurable Buffer storage 

supporting up to 128 messages. 

The Payload that can be supported by 

the controller during synchronous or 

aysnchronous transmission is userconfigurable. 

The number of transmit 

buffers in the FlexRay controller can 

be configured as well as the Receive 

buffers from a minimum of two to a 

maximum of 128 in powers of two. 

The block RAM resource utilization 

varies, based on the number of Transmit 

and Receive buffers and the configurable 

payload length. The depth of 

the Receive FIFO in the FlexRay controller 

can be user-configured from a 

minimum of two to a maximum of 128 

in powers of two. The core can be 

used in standalone mode or connected 

to Xilinx MicroBlaze or PowerPC 

processors. 

■ http://www.xilinx.com 

It is compatible with the diagnostic suite samDia, the sam- 

DiaX control element (ActiveX) and the samMCD3 Server 

(Standardized Runtime System for Vehicle Diagnosis). 

■ http://www.samtec.de

SPECIAL EDITION SPECIAL FLEXRAY EDITION · PRODUCTSl FLEXRAYl AUTOMOTIVE 

2007l35 


Esterel Technologies: 

Scade 6.0 now available 

From Esterel Technologies Scade 6.0 is now available. SCADE 6.0 

provides a unified modeling, verification and certified code generation 

capability called the ‘Unified Modeling Style’ that enables 

embedded systems and software developers to freely combine 

and nest arrayed data flow elements and state machines in a single, 

fully integrated environment. Developers of demanding safety-critical 

mixed data flow and state machines applications will 

benefit from this unprecedented modeling freedom enabled by 

SCADE 6.0 in terms of design and verification time decrease, 

enhanced generated code size and 

speed as well as greater design 

flexibility and reusability. Existing 

modeling solutions rely on the collaboration 

between two independent 

modeling editors; however, 

SCADE 6.0 simplifies the work of 

the application developer. Now, 

the developer can focus on the 

productivity of the modeling activity, 

in the knowledge that all the 

certification and verification optimization 

benefits of the previous 

SCADE releases are maintained. 

The process-centric SCADE 6.0 

“Certified Software Factory“ features 

eight fully integrated modules 

that support the process of creating 

safety-critical application 

software: 

• the design of the software 

models within the Unified Modeling 

Style, their integration with 

configuration management tools 

and the automatic generation of 

documentation, with SCADE 6.0 

Advanced Modeler 

• the traceability of the software 

models versus system requirements, 

with SCADE 6.0 Requirements 

Management Gateway 

(integrating TNI Software’s Reqtify 

technology) 

• the validation of the models 

through model test coverage 

(SCADE 6.0 Model Test Coverage) 

and formal verification of safety 

properties (SCADE 6.0 Design Verifier, 

powered by Prover Technologies 

A.B. Prover Plug-in for 

SCADE) 

• the automatic and certified code 

generation, with SCADE 6.0 KCG 

Qualified Code Generator, and its 

integration of the target platform 

• the verification of the correct compilation of the generated 

code and execution on the target platform with SCADE 

6.0 Compiler Verification Kit 

Several import/export capabilities are also enabled by 

SCADE 6.0, such as the import of system and software 

architecture, with SCADE 6.0 SysML/UML Gateway for 

Rhapsody and the import of algorithm designs. 

■ www.esterel-technologies.co



austriamicrosystems: 

High performance automotive ICs 

PRODUCTS 

LeCroy: Expanding Automotive Tests 

with Integrated FlexRay Trigger and Decode Capabilities 

With the AS8221, austriamicrosystems has developed 

a standard product for automobile data bus applications. 

The FlexRay transceiver IP is also licenced to Infineon, 

one of the world’s largest manufacturer of semiconductors 

for automotive applications. 

But the company offers a lot more for automotive application, 

e.g. micro-power A/D converter and a analog/mixed-signal 

foundry offering RF CMOS, High-Voltage 

CMOS, BiCMOS and SiGe-BiCMOS processes. 

austriamicrosystems’ business unit Full Service Foundry 

recently announced a further improvement of its 

design environment “HIT-Kit” for its advanced 0.35µm 

High-Voltage CMOS process H35. It is ideally suited for 

high voltage product design like power management 

products, display drivers, sensors and sensor interfaces 

and any kind of automotive applications just to 

name a few. The HIT-Kit 3.72 based on Cadence version 

5.1.41 includes updated periphery cell libraries up 

to 50V as well as the recently announced set of 20V 

LeCroy announces a FlexRay solution that provides complete 

trigger and decode capabilities for the WaveRunner 

Xi series of oscilloscopes. LeCroy’s solution correlates physical 

layer signals with protocol layer data in one display, 

and the FlexRay trigger 

hardware is completely 

integrated inside the oscilloscope. 

The internal FlexRay trigger 

can isolate static and 

dynamic slot IDs, cycle 

count number, frame qualifiers 

and symbols while 

the decoder shows a color 

coded overlay directly on 

top of the physical layer 

waveform. Since the trigger 

is not a node on the 

FlexRay network, no network 

re-programming is 

required, simply connect a differential probe to the bus and 

capture data. The user interface is easy to navigate, and the 

touch screen display provides easy access to all protocol 

triggers. Supported FlexRay protocol triggers include static 

and dynamic IDs, Frame Cycle Count, Frame Qualifiers 

(NFI, SyFI, StFI) and TSS Symbol. As with other serial data 

solutions, LeCroy features conditional triggering to set a 

trigger condition of in range, out of range, less than or greater 

than. This is ideal for triggering on a range of slot IDs 

or cycle numbers. 

LeCroy deconstruct physical layer serial data signals and 

display decoded data with visually intuitive color coded 

overlays. These overlays 

clearly identify different 

parts of the data being captured 

and allow the user to 

quickly identify the data of 

interest; speeding up the 

debugging process also for 

I2C, SPI, UART, RS-232, 

LIN. The solution offers the 

ability to decode 4 signals 

simultaneously. These 4 

signals can all be FlexRay 

or any combination of the 

protocols supported. Along 

with displaying decoded 

data overlaid on the waveform, 

an interactive table is provided. Entries in this table 

can be selected and automatically zoomed to preventing 

the need to scroll through long records. To further simplify 

how data is located a search function is built in to the zoom 

trace to quickly locate a specific slot ID or cycle number. 

This advanced set of tools works on live data as well as 

math functions and waveforms stored in memory 

■ http://www.lecroy.com 

devices optimized for power management products 

and display drivers in battery powered applications. In 

addition the HIT-Kit offers unique design utilities like 

Safe Operating Area Check (SOAC) tool, automatic layout 

generators for high-voltage device and guard-ring 

generation and special layout verification utilities like 

leakage check. 

The new Cadence HIT-Kit v3.72 contains a complete 

set of fully silicon-qualified standard cells, periphery 

cells and general purpose analog cells such as comparators, 

operational amplifiers, low power A/D and D/A 

converters. Custom analog devices, physical verification 

rule sets for Assura DRC/LVS/EXT, as well as excellent 

characterized circuit simulation models enable 

rapid design starts of complex high performance 

mixed-signal ICs. 

■ http://asic.austriamicrosystems.com/ 

hitkit/index.html


FLEXRAY · PRODUCTSl AUTOMOTIVE 

ESG: Space for 

Innovation and Growth 

With the removal of around 650 employees 

to Fürstenfeldbruck, ESG Elektroniksystem- 

und Logistik-GmbH has put its 

new company headquarters into operation. 

The new building replaces the previous 

headquarters, the ESG tower in 

Munich. At its new location, the company 

receives a modern building that has been 

tailored to the requirements of a high tech 

company. 

Recently the company has developed a 

simulation and demonstration platform for 

car driver assistance systems. The system 

with the name MoPAC, „Modular Platform 

for Automotive Applications“, enables ESG 

to simulate and assess any present and 

future assistance functions in a compact 

construction. Because of the system’s 

diversity of interfaces and ist open architecture, 

a multitude of connection possibilities 

for enhanced sensor systems and 

actuating elements is available. 

This system uses a central nodal point, 

based on an MPC5554 (microcontroller), 

to link various sub-functions to one another 

and to realise the overall function. A 

PC with a webcam 

is connected over an Ethernet interface. 

Furthermore, the platform communicates 

with other sensor systems and actuating 

elements via FlexRay, LIN, CAN and Zig- 

Bee (wireless). A specially adapted conveyor 

belt is used to simulate the driving 

surface. Enhanced control features are 

implemented on the central PowerPC 

2007l37 

platform and are strictly separated from 

the communication drivers both spatially 

and temporally by a virtualisation concept, 

so that high safety requirements can be 

adhered to. 

The system is also used to realise camerabased 

assistance systems, such as automatic 

distance control and avoidance 

manoeuvres. In doing so, efficient object 

recognition algorithms are used to locate 

vehicles in the setting. The PC takes on 

image processing and object recognition 

and supplies the positions of the located 

objects to the PowerPC via Ethernet. This 

information forms the basis for the integrated 

control algorithm, which is used to 

position a vehicle stably on the conveyor 

belt and to trigger responses to recognised 

foreign objects. The stabilised behaviour 

of the vehicle on the conveyor belt 

forms the basis on which the system 

intervenes into the driving process. 

The concept’s modularity means that it is 

possible to straightforwardly connect 

various bus systems, integrate enhanced 

sensor systems and control several vehicles. 

The concept also facilitates the realisation 

of assistance functions for which 

communicating vehicles are a prerequisite. 

ESG is providing an insight into the 

possibilities of car assistance systems 

and for this reason possesses a suitable 

integration and simulation environment 

for such systems. 

■ http://www.esg.eu 

FlexRay 

Analysis & Residual 

Bus Simulation 

FlexRay CCM 

Universal PC interface 

for FlexRay and CAN 

Open application 

interface 

Real-time residual bus 

simulation 

Multibus Analyser 

Transmission, reception 

and interpretation 

of FlexRay and CAN 

messages 

Open programming 

interface and scripting 

host 

Services 

Hardware and software 

development 

Consulting and training 

Leibnizstr. 15 . D-88250 Weingarten 

Tel.: +49-(0)751/5 6146 -0 

Fax: +49-(0)751/5 6146-29 

Internet: www.ixxat.de


Vector: 

Advanced FlexRay 

river Library 


The XL-Driver-Library for FlexRay from Vector 

Informatik is based on proven concepts of the XL- 

Driver-Library for CAN. FlexRay communication 

parameters are manually copied from the FIBEX 

database description to the application program. 

The standard functions of the XL-Driver-Library 

for FlexRay are supplied with the VN3300/ 

VN3600/VN7600 FlexRay interfaces for PCI and 

USB and also the XL-Interface-Family for PXI and 

PCMCIA. 

The XL-Driver-Library provides engineers with 

general and bus-specific methods that make it 

easy to operate the CAN, LIN, FlexRay and MOST 

interfaces. Channels and ports are managed with 

the general methods. Busspecific methods are 

used to configure network nodes and to send or 

receive messages. It is easy to assign logical 

application channels to physical device channels 

via the XL-Driver-Library or with the user-friendly 

Vector hardware configuration program. 

■ http://www.xxxxxxxxx.com 

CRST: One Day 

Seminar on FIBEX 

Software-Specialist CRST GmbH 

offers a one-day seminar about 

FIBEX in January 2008. After a 

brief introduction of XML the 

participants will learn in detail 

about the structure and theory 

of FIBEX. Practical exercises 

with FIBEX-Tools and an outlook 

on the future development of 

the FIBEX Standard will complement 

the theoretical part of 

the seminar. Mr. Ing. B. Sc. Thomas 

Bachmann, project manager 

software development at 

CRST GmbH and member of the 

ASAM-FIBEX group, will lead the seminar. 

The target group seminar are ECUs developers, 

vehicle network planers, firmware 

developers and decision makers with an 

emphasis FlexRay, MOST, CAN and LIN. At 

the end of the seminar, all participants will be 

able to understand or to plan content, features 

and the use of FIBEX. Each participant 

receives a certificate. 

■ http://www.crst.de 

PRODUCTS 

National Instruments: 

Easy programming 

with FlexRay Library 

National Instruments supports the development of FlexRay with 

a FlexRay Library for LabVIEW, a free, downloadable set of VIs 

(Virtual Instruments) for quickly and easily programming the 

necessary functions in a FlexRay communication network. The NI 

FlexRay Library contains 28 VIs (functions) for LabVIEW that make 

it easy for engineers and scientists to create initialization, read, 

and termination functions for FlexRay networks using the TZM 

FlexNode card (FlexRay PCMCIA interface). 

■ http://www.ni.com 

Book Presentation 

FlexRay - 

Fundamentals, 

Functionality, 

Applications 

The book contains all information about infrastructure and 

deployment of FlexRay Systems, protocol, access 

methods, synchronization, coding, frame size and configuration. 

Included is a CD-ROM with examples of code. 

The author Dr.-Ing. Mathias Rausch is working at Freescale 

since 1998. Since ist beginning he is involved in the 

development of the FlexRay protocol within the FlexRay 

consortium. This book is available in german language. 

Mathias Rausch 

FlexRay - Grundlagen, 

Funktionsweise, Anwendungen 

369 pages. Hardback. 

With CD-ROM 

€ 49,90 Euro 

ISBN 978-3-446-41249-1


2007l39 


Symtavision: SymTA/S 1.3 released 

Symtavision introduces the Version 1.3 of SymTA/S, its timing 

analysis and optimization tool for ECUs, busses and networked 

E/E-Architectures. It is available now with significant 

improvements over previous versions. 

The new end-to-end timing analysis allows under- and oversampling 

on synchronous and asynchronous systems, maximum-age 

and first-through semantics and end-to-end diagrams. 

A generalized import interface is customizable using PYTHON 

scripts with predefined imports for 

FIBEX, CAN and OSEK. The new scenario 

manager has a configurable parameter 

matrix and offers indvidual analysis 

per scenario. For OSEK libraries 

Symtavision added signal support for 

OSEK tasks and task chaining support. 

The comfortable COM layer gives visual 

feedback on input activation (e.g. 

transmission mode, transfer property). 

The FlexRay library will extend Sym 

TA/S to enable scheduling analysis and 

FlexRay Transceiver Experts 

for next generation vehicle networks 

Building the future 

in automotive solutions 

for over 25 years 

www.austriamicrosystems.com 

optimization for FlexRay buses. Key features will include: 

• Verification of message and signal transmission times 

• Calculation of signal jitter. 

• Considering COM-layer offset; Periodic, event-triggered 

and mixed frames; Multiple time-tables and different scenarios. 

• Seamless integration with FlexRay tools for modelling and 

configuration, e.g. EB, or customer-specific communication 

databases. 

• Exploration and optimization of 

FlexRay configuration, signal-tomessage 

and message-to-slot 

mapping, COM-task offsets, buffering 

(strategy, size) 

It will be possible to combine the 

FlexRay library with other libraries 

into system-level analysis and optimization. 

■ http://www.symtavision.com



PRODUCTS 

Freescale and Continental collaborate on 

multi-core 32-bit microcontroller for electronic braking systems 

Expertise in FlexRay 

The trend towards having more electronics in our 

vehicles has a significant role to play in tomorrow’s 

mobility. As an engineering service provider for 

complete vehicle development, the Bertrandt company 

is your professional partner for technologies 

orientated towards the future, and for challenging 

FlexRay projects. 

elektronik@bertrandt.com 

Bertrandt AG, Birkensee 1, D-71139 Ehningen 

To enable the next generation of EBS and chassis control 

systems, Freescale Semiconductor and Continental Automotive 

Systems’ EBS business unit in Frankfurt have joined 

forces to design a high-performance, multi-core microcontroller 

(MCU) optimized for EBS applications. the two 

companies are collaborating on a custom MCU called 

SPACE that is designed to provide the processing intelligence 

for Continental’s next-generation EBS products. The 

SPACE device integrates three e200 cores based on Power 

Architecture technology, making it the industry’s first triplecore 

automotive MCU. Designed to double the performance 

of existing MCUs, the highly integrated SPACE 

device contains 3 MB of flash (one of the largest MCUbased 

flash arrays), 96 KB of SRAM, advanced FlexRay 

technology and Continental’s unique fail-safe technology, 

which fulfills all requirements for Safety Integrity Level 3 

(SIL3) applications. he joint design program to create the 

SPACE device has entailed a major investment in software 

and hardware tools, including low-level drivers (LLDs), 

development tools, evaluation boards and cycle-accurate 

simulation software for virtual prototyping at the systemlevel. 

The LLDs to be used with SPACE are planned to be 

compliant with the AUTOSAR standard. 

The multi-core SPACE device, currently available in 130- 

nanometer process technology, is the first member of a 

comprehensive MCU family, with a roadmap to higher performance 

planned on 90-nanometer process technology. 

■ www.freescale.com/files/pr/automotive.html 

Softing: 

Hardware platform 

for diagnostics and 

flash programming 

The EDICflex interface is a hardware platform which 

was designed to suit the requirements of FlexRay. 

EDICflex communicates with the PC via Fast-Ethernet 

TCP/IP and can process large amounts of data 

without any problems due to its powerful microcontroller. 

The interface is linked to the FlexRay bus 

via the FlexRay chip Freescale MFR4300. An upgrade 

to new chip generations is realized with plug-in 

IP modules. In addition to two FlexRay channels (10 

MBit/s), the interface has two CAN channels (ISO 

11898-2 HighSpeed and ISO 11898-3 LowSpeed). 

The FlexRay and CAN messages can thus be acquired 

on the same time basis. Four trigger outputs and 

two trigger inputs are available for combination with 

external hardware components. 

The flexible software architecture of EDICflex allows 

a seamless integration of the optional „Embedded 

diagnostic module“, which contains a protocol stack 

with FlexRay transport layer and UDS diagnostic 

service processor. For custom specific applications 

the diagnostic module can be combined with an 

optional PDUAPI software interface. Custom specific 

applications and adaptions can be implemented 

on request as well. The robust housing allows flexible 

use in the lab, test benches, test vehicles and in 

production environments 

■ http://www.softing.com


2007l41 


Model-based Test Automation 

for MiL, SiL and HiL 

K2L: MoCCa Vario II 

The K2L MOST/CAN/Flexray/TCP/IP-Gateway MoCCa Vario 

II is an out of the box solution to create automotive gateways 

between multiple physical buses and different logical 

protocols like ISO-Transportation Protocol. It allows you to 

create, modify and run your own advanced gateway tables 

for transferring messages and signals between different 

buses and protocols or to create repeaters on a single bus. 

Based on a table driven approach, the definition and exchange 

of the Conversion Rules (gateway table) is easily possible 

without any re-compilation of the MoCCa Vario II firmware. 

The MoCCa Vario II gateway tables are configured 

with the configuration tool UGW Composer. It assists 

developers in defining their own Message Conversion 

Rules and generates Gateway Configuration Tables in 

human readable- and in several binary formats. UGW Composer 

allows direct editing of CAN- and MOST- Messages 

as well as the import of Message Databases from various 

3rd party formats. 

■ http://www.k2l.de 

MESSINA is the software platform from for model-based 

ECU testing from specification to HiL test stand. Hardware 

independent test sequences can be used seamlessly in 

the model test (MiL), software test (SiL) and hardware test 

(HiL). Therefore, the test strategy can be extended across 

processes between OEM and supplier. 

The outstanding feature of MESSINA is the possibility to 

reuse MATLAB/Simulink models, ASCET models and 

AUTOSAR software components from the ECU development 

in a test scenario. These models can be dynamically 

integrated at runtime and executed in parallel. 

The tests are either described in Java or UML notation. The 

modular Eclipse based design of MESSINA simplifies the 

integration of further editors for test case description. 

Thus, MESSINA can be perfectly integrated into different 

customer environments. MESSINA reaches a better test 

coverage for distributed ECU development providing easy 

portability of test sequences to different test systems. 

The test cases in MESSINA are described text-based or 

graphically through additional editors (e.g. using the UML 

Testing Profile). All necessary control structures for the 

description of complex test sequences are available. 

Recurrent test steps can be defined as templates in a test 

library and pasted into the test sequence through drag and 

drop. Test variants can easily be created by parametrizing 

generalized test cases and thus bringing a considerable 

increase in test coverage. 

During the test creation process, the symbolic signals of 

all models and I/Os used in the test environment are provided 

through a global signal pool. The creation system 

allows the comfortable remote debugging of test cases 

directly on the target system. 

■ http://www.berner-mattner.com 

Turning System Expertise into Value 

ESG is your expert for automotive electronics with services 

throughout the life cycle: 

Electronic system development and integration 

Customer oriented consulting 

Custom tailored technical and non-technical training 

Logistic service offerings 

After-sales solutions 

ESG Elektroniksystem und Logistik-GmbH www.esg.eu 

Frankfurter Ring 211 D-80807 Munich Tel. +49 89 9216-1831



GiN: FlexRay 

Probe 

To access FlexRay networks GiN offers a new Flex- 

Ray Probe as extension to MultiLog, GiNs high-end 

data logger, for the recording of FlexRay events. 

Compared to a controller-based standard solution 

also events from an unsynchronized bus (eg. Communication 

StartUp) can be recorded. It allows logging 

without knowledge of the bus parameters. 

The features of the Probe leveraging a Philips 

TJA1080 as FlexRay-Transceiver are: an offboard 

interface together with 2.5 m cable capable of 10 

Mbit/s, recording of frames and symbols, support 

for up to 2 FlexRay interfaces including wake-up. 

The temperature range is- 40° to + 70 °C, with an 

internal supply voltage of + 3 V, +5 V and Vin from 

the MultiLog (5 V ... 30 V). The interface has dimensions 

of 60 x 67 x 37 mm, its weigth is 100 g. 

■ http://www.gin.de 

ADVERTISERS 

Austriamicrosystems AG, 

A-Unterpremstätten.....................39 

Bertrandt AG, 

Ehningen .....................................40 

Bosch GmbH, 

Stuttgart.......................................43 

dSpace GmbH, 

Paderborn ....................................23 

Elektrobit Austria GmbH, 

A-Wien ..........................................2 

ELMOS Semiconductor AG, 

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

ESG GmbH, Fürstenfeldbruck......41 

ETAS GmbH, Stuttgart...................1 

IXXAT Automation GmbH, 

Weingarten..................................37 

LeCroy Europe GmbH, 

Heidelberg ...................................19 

Mentor Graphics (Deutschland) 

GmbH, München ........................15 

NEC Electronics (Europe) GmbH, 

Düsseldorf...................................35 

samtec automotive 

software & electronics gmbH, 

Filderstadt ...................................27 

Softing AG, Haar ............................9 

TietoEnator Deutschland GmbH, 

Stuttgart.......................................33 

TTTech Computertechnik AG, 

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

TZ Mikroelektronik, 

Göppingen...................................31 

Vector Informatik GmbH, 

Stuttgart.......................................44 

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 

Member Listing 

You will find a list of the current members of the 

FlexRay Consortium on the Consortiums Website: 

www.flexray.com. Follow the link 

[about FlexRay] [current members] 

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 2007 

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.

with LABCAR - HANSER automotive

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?