Vector Press Book

Press Book_Einleitungsseiten:Einleitungsseiten
09.02.2010
Press Book
1 st Edition
14:27 Uhr
Seite 1
09.02.2010
14:27 Uhr
Seite a
Date: February 2010 Responsible for the contents: Vector Informatik GmbH, Stuttgart, Germany
All mentioned product names are either registered or unregistered trademarks of their respective owners. The constant worldwide availability of all products or services is not warranted.
No information contained in this catalog may be reproduced without expressed permission, in writing, from Vector Informatik GmbH.
Errors and omissions excepted.
Illustration & Design: SATZTEAM Fotosatz & Neue Medien GmbH, Eberdingen, Germany
10.02.2010
12:05 Uhr
Dear reader,
in recent years, Vector has written together with customers - numerous technical articles reporting
on standardization trends, development processes and software architectures for embedded systems.
In this way, we have provided our readers with a wealth of knowledge. Now you get a central point of
access to this know-how.
In this book, you find a selection of the best technical articles in a convenient and compact format.
These articles cover important topics such as design, development and test of networks, ECU calibration and diagnostics as well as process management.
We hope very much that you find this book both useful and informative.
Enjoy reading.
Sincerely,
Dr. Thomas Beck

President
Seite b
09.02.2010
14:27 Uhr
Seite c
Contents
Serial Bus Systems
Serial Bus Systems in the Automobile: Introduction

Motivation, advantages, tasks and architecture of serial bus systems in the automobile
1/0
Serial Bus Systems CAN
Serial Bus Systems in the Automobile: CAN

Reliable data exchange in the automobile with CAN
1/6
Serial Bus Systems LIN
Serial Bus Systems in the Automobile: LIN

Simple and cost-effective data exchange in the automobile with LIN
1/12
Network Development across LIN Bus Systems

Tools for efficient network design and conformance testing
1/18
Assuring the Quality of LIN ECUs

Current and future strategies for LIN Master conformance tests
1/22
Serial Bus Systems in the Automobile: FlexRay

FlexRay for data exchange in highly critical safety applications
1/26
The Optimal Operating System for FlexRay-Based Applications
1/32
Embedded Software for FlexRay Systems

Special aspects and benefits of implementing modularized software
1/38
FlexRay becomes daily Routine

Analyzing, simulating, and testing FlexRay ECUs and networks using CANoe.FlexRay
1/42
Case Study: Bertrandt
1/45
FlexRay Sets the Pace

Real-time simulation of FlexRay systems
1/46
Efficient Access to the FlexRay Bus

High-performance FlexRay hardware for analysis and simulation
1/50
AUTOSAR PDUs Conquer FlexRay

Audi benefits from CANoe.FlexRay in developing FlexRay networks with PDU communication
1/54
Beyond FlexRay
Requirements on a modern development environment
1/58
Serial Bus Systems MOST
Serial Bus Systems in the Automobile: MOST

MOST for transmission of multimedia data
1/62
ECU Testing
Efficient Testing in Automotive Electronics

One test environment from HIL simulation to diagnostics
2/0
Reliable Engineering Testing on a Wiper Motor Test Bench

Time-synchronous recording and evaluation of bus messages and physical parameters
2/8
Case Study: Nippon Seiki Co., Ltd.
2/13
Comprehensive ECU Tests with Fault Simulation

Fault simulation capability is needed in early test phases for efficient functional tests
2/14
Semi-Synthetic Regression Tests with Real-World Data

Reducing time and hardware effort in software evaluations
2/20
Model-Based Testing for Better Quality

Advantages of test case generators in model-based development processes
2/24
Efficient Airbag ECU Tests

Increase efficiency by automated tests during development
2/28
Vehicle Diagnostics - The whole Story

Efficiency gains by standardization and the use of tool-supported processes
3/0
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration

and Validation Assistant
3/8
A Source Code Generator Approach to Implementing Diagnostics in Vehicle ECUs
3/16
ECU Software for Dry Dual Clutch has Stringent Requirements

Integrated diagnostic and flash solution with script control
3/20
Flexible Flash Solution for every Job

Open standards enable use of generic tool chains
3/24
Flash Programming via CAN requires Suppliers Flexibility

Satisfying strict requirements of Vehicle OEMs
3/28
Serial Bus Systems FlexRay
Vehicle Diagnostics
ECU Calibration
09.02.2010
14:27 Uhr
Seite d
Use of XCP on FlexRay at BMW
4/0
XCP-on-FlexRay at Audi
AUTOSAR-compatible XCP software modules for FlexRay ECUs
4/4
XCP at the Focal Point of Measurement and Calibration Applications
4/10
Quantum Leap in Microcontroller Measurement Technology

Innovative ECU measurement concept for maximum data rates with
minimal effects on execution time
4/16
Efficient Analysis of Model Behavior in ECU Function Development

Visualize and parameterize Simulink models easily and efficiently
4/20
Accelerated Turbocharger Development with CANape

Efficiently developing control concepts with a cost-effective rapid prototyping solution
4/24
Optimizing Driver Assistance Systems

Verification of object recognition algorithms by driver assistance systems
4/28
Trends in Embedded Development

Requirements and future concepts in hardware, software and tools
5/0
Timing, Memory Protection and Error Detection in OSEK Systems

Requirements on a real-time and multitasking operating system
5/4
Current Challenges in Automotive Networking

Reusability of software modules at Volkswagen and Bosch
6/0
The Universal Gateway ECU

Flexible post-build configuration of AUTOSAR gateways
6/4
Early Migration creates Opportunitites for Innovations

Mix of individual software and AUTOSAR components in vehicle electronics
6/10
AUTOSAR on its Way to Production
6/14
AUTOSAR: New Paths to ECU Software Part 1

Iterative collaboration between OEM, TIER1 and software supplier
6/18

AUTOSAR in practice Life cycle of AUTOSAR ECU software
6/24
Networking Heavy-Duty Vehicles Based on SAE J1939

From parameter group to plug-and-play application
7/0
CAN and J1939 under Extreme Duty Conditions

Vehicle electronics guarantees functionality in cold, ice and snow
7/6
Current Trends in Network Development for Heavy-Duty Vehicles

Factors of success in electronic development
7/14
Open Networks - ISOBUS
Automatic Interoperability Tests for ISO11783 Systems

Universal test solution assures compatibility
7/18
Open Networks - IP
Wireless Analysis in a Multi-Protocol CAN Environment
7/22
Moving Communication
Wireless analysis of in-vehicle networks
7/26
Prototyping and Testing CANopen Systems

Reaching goals rapidly with minimal effort
7/30
Automatic Testing of CANopen Devices
7/34
Before considering Tools it is easy to have a Handle on the Process first

Interview about the management of engineering and management processes
in the E/E development
8/0
Tool-supported Data and Process Management at MAN Nutzfahrzeuge AG

An integrated development database manages all engineering data in
the E/E development process
8/2
From Pilot Studies to Production Development

Efficiency and quality in calibrating transmissions
8/6
ECU Software
AUTOSAR
Open Networks - SAE J1939
Open Networks - CANopen
Process Management
01 Press Book_Seite_1-00_1-05:Press Report 1
09.02.2010
13:07 Uhr
Seite 1
Serial Bus Systems in the Automobile

Part 1:
Motivation, advantages, tasks and

architecture of serial bus systems in
the automobile
The share of electronic components in the automobile is growing from year to year. Electronics
plays a decisive role, not only in satisfying primary customer wishes for better driving safety and
comfort, but at the same time to achieve better
fuel economy and reduced exhaust emissions. Another
aspect that should not be underestimated is the contribution by numerous serial bus systems in the automobile. Many functions would not even be possible
without data exchange between electronic components. This ar ticle of fers some initial insights into the
world of serial bus systems in the automobile.
Motivation and advantages of serial bus systems
in the automobile
Recent history of the automobile is character ized by intensive electronification. The driving force for this originates
primarily from customer expectations of a modern automobile which are becoming increasingly demanding. Moreover,
legislators are continually placing stricter requirements on
exhaust emissions. The rising competitive and cost pressures
of globalization also produce constant innovative pressure.
Automotive OEMs have found electronics to be a way to meet
this multiple challenge. Par ticularly this is reflected in the
migration of electronic control units (ECUs) into the automobile which began at the end of the 1970s.
communication channel integrates all individual communication channels and is referred to as a bus. Using this bus
and associated serial inter faces it is possible to join all ECUs
together into a network refer to as a serial bus system (Figure 1). In this context, ECUs are referred to as bus nodes.
Since the introduction of serial bus systems, the complex
and of ten divergent types of wire harnesses in the automobile have become a thing of the past. Bus systems not only
simplify project design and installation, but also reduce the
weight and space required for wir ing. Moreover, the lower
At that time, the first embedded electronic systems still per formed their tasks fully autonomously. However, very early it
was recognized that by coordinating applications placed in
dif ferent ECUs, it would be possible to increase vehicle functionality immensely. This was the motivation for integrating
communication systems in the automobile.
Ahead of everything else, at that time it was electronic driving dynamics control that dominated advanced development. However the intensive wir ing ef fort utilizing individual dedicated lines only permitted limited data exchange. As a
way out of this dilemma, bit-serial data exchange via a single communication channel came into question. This single
1/0
Figure 1:
Bus networking: All electronic control units (Black:
Bus nodes) are joined into a system network, the serial
bus system, by means of a bus and related serial inter faces.
number of connectors reduces the susceptibility to failure

signif icantly. These many advantages face numerous communication tasks that must be mastered by the serial bus
system. The most impor tant communication tasks are discussed in the following.
Communication tasks
A precondition for trouble free serial data exchange is the
unique allocation of the data to be sent to the bus nodes. Essentially a distinction is made between sender-selective and
receiver-selective allocation (addressing). In case of senderselective addressing the sender identifies the desired receiver by a unique bus node address. In contrast, in case of receiver-selective addressing the data to be sent are addressed. This means in principle that all data are available
for any node to receive (Broadcast). Therefore all bus nodes
have the task of filter ing out data that are relevant to them.
This is accomplished with the help of the address referred to
here as identifier.
In order that the receiver acquire the data and address as
one unit, the sender packs both of them together as a frame.
A typical frame encompasses the address and data with a
start and end recognition, which are primarily used to synchronize senders and receivers. A frame is also referred to
as a message.
09.02.2010
13:07 Uhr
Seite 1/1
The most pressing tasks of a serial bus system include realtime communication and data integrity. A distributed system
can only fulfill its intended purpose if all data reach the destination node in time and without errors. A serial bus systems per formance and field of application in the automobile
substantially depend on the degree with which it can avoid,
reject, detect and correct errors, and can guarantee timely
data transport.
Data integrity
Quantitatively data integrity can be described as the residual
error probability. This is a statistical measure of data integrity violation. Residual error probability is understood as the
product of probability A that the transmitted data are corrupted and probability B that the corrupted data remain undetected. The data integrity of a serial bus system therefore
depends first on the extent to which it avoids the corruption
of data, and second on the degree to which it can detect corrupted data.
Var ious interactions related to electrical, capacitive or inductive coupling, as well as electromagnetic fields, come into consideration as potential causes of data corruption in
the automobile. Specif ic sources responsible for corruption
might be actuators, fan motors, high-frequency signals generated by the commutation process in DC motors and fast da-
Figure 2:
Controlled and
random bus access.
1/1
09.02.2010
ta transmissions or reflections at the ends of buses. The

more successfully these causes can be eliminated, the greater the noise immunity and more reliable the data transmission.
To enhance the noise immunity of a serial bus system, cer tain impor tant measures are necessary. Besides shielding
the transmission medium, as well as all electrical and electronic components, it is impor tant to provide suf ficiently
large distances between data and power transmission lines
and between electrical and electronic components. Fur thermore, it is impor tant to limit the data transmission frequency and number of data signal edges and their steepness, to
apply the principle of dif ferential signal transmission and finally to terminate bus ends with the character istic impedance of the transmission medium. Even with optimal physical system design transmission errors cannot be eliminated
entirely. Error detection mechanisms are therefore essential.
Among the most frequently utilized methods is the checksum
method, wherein the sender computes a checksum from the
data block to be sent by a defined algorithm. It then sends
this checksum at the end of the data block. Using this checksum the receiver is able to ver ify the received data block.
13:07 Uhr
Seite 1/2
The more clever the algorithm, the shorter the data block to
be protected and the longer the checksum, the better the algorithms error detection ability. However, due to limited
bandwidth and time requirements, a compromise must be
reached between error detection ability and the ratio between data block and checksum size (transmission ef ficiency). Fur thermore one must consider that the checksum itself
is not immune to disturbances dur ing transmission.
As a rule, after detecting a transmission error, error correction is needful, e.g. by means of an error-correcting checksum. However, unlike simple error detection that would
require an explicit longer checksum. For ef ficiency reasons
error-correcting checksums are not implemented in the automobile. The error correction happens by repeating the
message: caused either by an error flag set by the bus node
detecting the error, or automatically in the case of periodic
message transmission.
Real-time capability
A system with real-time capability must be able to guarantee
transmission of all data to be exchanged between the var ious bus nodes within a defined time window. Key factors
Figure 3:
Simplified architecture of serial bus
systems.
1/2
09.02.2010
13:07 Uhr
Seite 1/3
SE RI AL BUS SYS TEMS IN THE AU TO MO BILE
here are the number and sizes of messages, the available

bandwidth, and especially the type of bus access. In the latter case a fundamental distinction is made between controlled and random bus access (Figure 2).
In serial bus systems with controlled bus access, bus access
rights are already clearly defined before the bus access. Such
systems of fer deterministic message traf fic as an impor tant
precondition for attaining real-time capable serial bus systems. However, since the entire communication sequence is
executed according to a schedule and cannot be influenced,
serial bus systems with controlled bus access are character ized by poor dynamic behavior.
This disadvantage does not apply to bus systems with uncontrolled bus access. Each bus node has the right to occupy the
bus at any time, e.g. in response to an event that just occurred. This produces very fast bus access; however there is
the inherent risk of more or less acute collisions, depending
on the event density, message sizes and the available data
rate. These are not good conditions for achieving real-time
capable data transmission.
Monitor ing of the bus by bus nodes wishing to send signif icantly reduces the risk of collision. It can be prevented entirely by introduction of message prior ities. However, these
bus access methods based on bus monitor ing and message
prior ities cannot guarantee timeliness. It is possible, that
low-prior ity messages will be delayed unreasonably long.
Architecture of serial bus systems and bus nodes

in the automobile
Based on the reference model for data communication specified by ISO (International Standardization Organization),
the serial inter face of a bus node in the automobile is typically subdivided into two (communication) layers: A lower
layer (Physical Layer) and a layer above it (Data Link Layer).
Some of the tasks handled by the Data Link Layer are addressing, framing, bus access, synchronization and error detection and correction. These tasks are defined by a communication protocol. The Physical Layer specification, on the
other hand, covers all aspects of the Physical Layer, from the
physical bus inter face to physical signal transmission over
the bus.
Generally the physical bus inter face is implemented with the
help of a transceiver. A communication controller covers the
Data Link Layer. If all of the bus nodes within the system follow the same communication protocol and the same Physical
Layer specification, then the fundamental preconditions for
trouble-free data exchange between the bus nodes are satisfied.
In serial communication the senders application passes to
the communication controller the data block to be sent. The
communication controller in turn adds the address and
checking and synchronization information to the data block,
thereby creating a frame. The transceiver now transmits the
frame over the bus. In the automobile the physical interconnection structure is generally the line topology, which is very
easy to manage due to the passive bus inter face. On the receiver side the transceiver accepts the frame and passes it to
the communication controller, which evaluates the information transmitted to it and in case of correct data reception
routes the data block to the application.
This results in a hierarchical and therefore transparent communication flow. This is guaranteed by completion of the
communication tasks assigned to the layers, and by the communication protocol and def inition of the Physical Layer
(Figure 3).
For some tasks such as bus management (including Sleep
and Wake-Up functionality) or diagnostics and configuration
of bus nodes, the communication functionality provided by
the Data Link Layer is insuf ficient. By def inition higher layers respectively higher communication protocols the communication functionality can be expanded.
CAN, LIN, MOST and FlexRay

Intensified competition is contributing toward more and
more safety and convenience functions in the automobile.
This not only results in a permanent increase in the number
of electronic components in vehicles, but also a substantially
greater degree of networking with rapidly escalating data
1/3
13:07 Uhr
Seite 1/4
volumes, since most new automobile functions cannot do

without data exchange any longer. To keep the growing complexity of automotive electronics manageable, automotive
OEMs create dif ferent standards on the system, functional
and communications levels. On the system or functional level, AUTOSAR (Automotive Open System Architecture) is expected to provide the necessary transparency in the future.
Non-proprietary communication standards such as CAN, LIN,
MOST and FlexRay provide greater transparency on the communications level.
CAN was developed in the early 1980s by Robert Bosch

GmbH, and in 1994 it became an international standard
(ISO 11898). Three of Vectors executive directors played
key roles in its development, and in 1988 they founded
Vector Informatik GmbH. LIN, MOST and FlexRay emanated
from non-proprietary organizations: The LIN Consor tium
(www.lin-subbus.org), MOST Cooperation (www.mostcooperation.com) and FlexRay Group (www.flexray.com). Although
they have not been of ficially standardized, they can be considered de-facto standards.
CAN (Controller Area Network) is used primarily in the power train, chassis and convenience areas. LIN (Local Interconnected Network) serves to achieve simple and cost-ef fective
data transmission in the sensor/actuator area. MOST (Media
Oriented System Transport) is implemented in infotainment
to transmit video and audio signals. Finally, FlexRay enables
the most challenging communication in safety-critical distributed applications. Figure 4 shows an example of ECU networking with serial bus systems in a modern automobile. In
contrast to CAN, LIN and MOST, however, FlexRay must first
become established in the automobile. This fall the first
FlexRay production application will hit the streets. The Munich automotive producer BMW is introducing the innovative
bus system in an active suspension control system on its new
X5 automobile.
Reliable partner for ECU networking and data

exchange
Author:
Eugen Mayer (Graduate Engineer with Technical Teaching Cer tif icate), after completing
his vocational training to become a communications technician, studied electronics at
the Technical College in Ravensburg/Weingar ten, Germany, and studied electrical
engineer ing and vocational teaching at the
University of Stuttgart. Since 1999 he has
been working at Vector Informatik where he
is employed as a Senior Trainer.
Tel. +49-711/80670-574, Fax +49-711/80670-111,
E-Mail: eugen.mayer@vector-informatik.de
1/4
09.02.2010
The specialists at Vector support automotive OEMs and suppliers in CAN, LIN, FlexRay and MOST networking with a universal tool chain of design and development tools as well as
software components and base software for AUTOSAR ECUs.
Advising, consulting services and tools for process management supplement the application areas. Its services are complemented by a broad-based training program on Vector
tools, software components and serial bus systems.
For entry-level work in automotive ECU networking or data
exchange the Stuttgart-based company of fers the one-day
seminar Serial bus systems in the automobile. Fundamentals seminars on CAN, LIN, FlexRay and MOST are best
suited as introductions to the var ious development activities
related to automotive electronics. Additional information
and schedules one can find on the Internet:
www.vector-informatik.com
Outlook
Parts 2-5 of this series address the serial bus systems CAN,
LIN, FlexRay and MOST in detail.
09.02.2010
13:07 Uhr
Seite 1/5
Developing automotive
OFUXPSLJOHJTOPUSFBMMZEJGDVMU
once you have learned how to do it.
Whether you are new to the field of automotive electronics or
are an experienced pro, at the VectorAcademy you will certainly find the right workshop for your knowledge level. Your
benefit: You just sign up for the learning modules that you
really need.
CAN, LIN, FlexRay, MOST, AUTOSAR, Embedded Software...
instead of searching for answers in the books, quiz our trainers. This is the most effective way to acquire knowledge and
skills. We guide you through practice-oriented exercises. And
you have the opportunity to share your experiences with colleagues from your field.
Dont settle for less. And it costs less than you might think.
Get a quick overview at our web pages.
www.vector-academy.com
7FDUPS"DBEFNZ8PSLJOH,OPXMFEHF
Vector Informatik GmbH

Ingersheimer Str. 24
70499 Stuttgart
Tel. 07 11 / 8 06 70-0
www.vector-academy.com
new?
thing
some harge
y
r
t
to
fc
Want our free o
tal:
Visit
g Por
in
om
n
r
a
ing.c
n
E-Le
r
a
-ele
ector
.v
w
ww
09.02.2010
13:10 Uhr
Seite 1

Part 2:
Reliable data exchange in the automobile with CAN

The relentless pace of globalization has brought growing competitive pressure to bear
on automotive OEMs and suppliers, which in turn leads to one innovative of fensive after
another. Electronics plays a decisive role here: Increasingly complex electronic systems
provide for a high level of safety and comfort in car driving. The CAN (Controller Area
Network) serial bus system makes a crucial contribution here with to its specif ic proper ties. It assures reliable data exchange even under harsh environmental conditions for
example. This technical ar ticle is intended to serve as an introduction to CAN technology.
CAN standard, implementation and inter face

The CAN technology developed by Bosch [1] has been standardized since 1993 and exists as ISO Standard 11898 which is
organized in several parts (Figure 1). The first part contains
the CAN protocol and covers the entire data link layer (framing, addressing, bus access, data assurance) and part of the
physical layer (physical signaling) of the standardized reference model for data communication (ISO 7498). In the
meantime a large number of cost-ef fective CAN controllers
have become available which implement the CAN protocol in
hardware.
The second part describes the CAN High-Speed physical layer, and the third part the CAN Low-Speed physical layer. These two parts cover the Physical Layer of ISO 7498 (including
physical bus inter face, data rates and voltage levels). The
CAN High-Speed physical layer is used primarily in power train and chassis applications. It is essentially implemented
by the CAN High-Speed transceiver, which supports a maximum data rate of 1 MBit/s. The CAN Low-Speed transceiver
with a maximum data rate of 125 KBit/s is generally used for
the CAN Low-Speed physical layer that is primarily used in
the body/convenience area.
Accordingly the CAN inter face (Figure 2) consists of a CAN
controller and a CAN transceiver. While the CAN controller
handles the CAN protocol, the CAN transceiver assumes the
task of physically coupling the CAN controller to the CAN bus
operated in dif ferential signal mode. Dif ferential signal
transmission enhances noise immunity and requires two
Figure 1:
CAN in the reference
model for data communication (ISO
7498), CAN standard
and implementation.
1/6
communication lines (CAN-High and CAN-Low line), which

are terminated with the character istic line impedance to
avoid reflections at the ends.
09.02.2010
13:10 Uhr
Seite 1/7
hardware or software of existing bus nodes. However this is

only true if the added bus node is exclusively a receiver.
Event control
Message distribution
Message addresses and message filters are used in a CAN
network to organize nodes and messages. Message addresses, commonly referred to as Identifiers (ID) do not identify
the CAN target nodes, rather they identify the messages
themselves, so that in principle all CAN messages are available to be received by all CAN nodes (message distribution).
By means of a filter each CAN node selects those CAN messages from the message stream that are relevant to it (receiver-selective system). The 11 bit wide ID permits specification
of up to 2048 CAN messages in a CAN network.
The messages that are transmitted in a CAN network and

their sequence do not depend on a time progression, rather
they depend on the occurrence of special events. Each CAN
node is in principle author ized to access the CAN bus immediately after an event occurs. Given its relatively short message length of max. 130 bits in standard format and its high
data transfer rate of up to 1 MBit/s, this method enables
quick reactions to asynchronous events. This is an impor tant
precondition for real-time capable data transmission in the
millisecond range (1 to 10 ms), which is primarily a requirement of power train and chassis applications.
Message distribution of fers the following advantages:

> Cost savings by shared use of sensors,
> Easy implementation and synchronization of distributed
processes, and above all:
> High flexibility with regard to the configuration.
This is because omitting node addresses makes it possible to
integrate other bus nodes without having to modify the
Since CAN communication is not based on any time schedule

the message traf fic is not determined until runtime, and this
implies that it carries the inherent risk of collisions. This risk
increases with increasing bus load, and it calls the real-time
capability of the system into question. To assure real-time
data transmission in spite of random bus access, the
CSMA/CA bus access method is utilized in the CAN network.
Figure 2:
CAN inter face and
CAN network.
1/7
09.02.2010
CSMA/CA bus access method

Bus access begins when a CAN node wishing to send first listens to the CAN bus (Carrier Sense CS). If the CAN bus is
available the CAN node may begin to transmit its message
immediately. On the other hand, if it detects bus activity it
must postpone its send request until the CAN bus is available
and the currently running message transmission has been
completed; in addition it must wait a duration of three bit
times (ITM Intermission). An ongoing message transmission
is not interrupted in this method bus access is nondestructive.
If there are multiple CAN nodes wishing to send, bitwise arbitration (Figure 3) prevents collisions from occurring in
spite of simultaneous bus access (Multiple Access MA). In
the framework of bitwise arbitration all CAN nodes wishing
to send place the IDs of the CAN messages they wish to send
bitwise on the bus, from the highest to the lowest signif icant
bit. The wired-AND bus logic (0=dominant) that forms the
basis of the CAN network ensures that there is always an unambiguous bus level. After adding on an ID bit, each CAN
node compares the bus level with the level it sent. The arbitration logic decides whether a CAN node may continue to
send or whether it must stop sending. At the end of the arbi-
13:10 Uhr
Seite 1/8
tration phase the CAN node that gets send author ization is
the node transmitting the CAN message with the least signif icant identifier. Lower prior ity CAN nodes first switch to the
Rx state and access the CAN bus for a renewed send attempt
as soon as the bus is free again.
Not only do the bus and arbitration logic prevent collisions
(Collision Avoidance CA), they also provide prior ity-controlled bus access: The lower the signif icance of the identifier, the higher the prior ity of the CAN message, and this results in faster bus access. The CAN message with the smallest
identifier (ID=0) will therefore be transmitted without delay.
If the bus load is not too high, this type of random, nondestructive, prior ity-driven bus access facilitates correct and
very fast bus access. On the one hand, it should be noted
that delays grow with increasing bus load, above all delays of
low prior ity CAN messages. In the worst case a situation may
arise in which CAN messages arrive too late at receivers or
are suppressed entirely. On the other hand, the CSMA/CA bus
access method produces a reciprocal relationship between
network extension and maximum data rate. Dur ing bitwise
arbitration a recessively sending CAN node must be able to
Figure 3:
Wired-AND bus logic,
arbitration logic and
bitwise arbitration
based on example of
two CAN nodes.
1/8
09.02.2010
13:10 Uhr
Seite 1/9
reliably detect a dominant level. The bit time inter val should
therefore be sized such that signal propagation times on the
CAN bus are fully compensated. A length extension to a network therefore necessitates a longer bit time inter val, which
in turn defines a maximum usable data rate.
Data transmission
It is primarily Data frames that are responsible for data
transmission in the automobile (Figure 4). While in fact Remote frames also exist for requesting data, they are hardly
ever used since data transmission in the automobile is not
typically request-based, rather it is primarily provided on
the information generators own initiative. The two types of
frames have identical layouts; the only dif ference is that the
data field is omitted in the Remote frame.
A basic prerequisite for transmitting Data and Remote frames is synchronism between sender and receiver. Since a
clock line has been omitted for reasons of cost and ef fort,
synchronism is achieved by signal edges and a well-defined
resynchronization mechanism. Each message transmission
begins with transmission of the dominant synchronization
bit (SOF Start of Frame) and this generates the first signal
edge (Bus-Idle exhibits a recessive bus level). The receiver
ensures synchronization over the entire transmission by
evaluating each arriving signal edge and adapting its own
bit timing as necessary. The bit stuff ing method ensures that
a complementary bit (stuff bit) appears at the latest after
five homogeneous bits, thereby providing a signal edge.
Following the SOF is the ID, which may be either 11 bits

(Standard-ID) or 29 bits (Extended-ID) in length. The standard format dominates in the automotive field. The extended
format typically plays a role in conjunction with higher level
protocols such as SAE J1939. The ID format being used is indicated by the IDE (Identifier Extension) bit. Another bit
switch (RTR bit Remote Transmission Request) indicates
whether the frame is a Data or Remote frame.
The 64 bit wide data field is available for transmitting useful
information, in which the exact number of useful bytes is indicated by a DLC (Data Length Code). Following the data
field is the so-called CRC sequence (CRC Cyclic Redundancy
Check). The sender generates the CRC sequence based on all
bits to be transmitted, a generator polynomial and a welldefined algorithm. Independent of the message filter ing the
same process occurs at the receiving end with the arriving
bits. The two sequences are compared, and the acknowledgment is made after the recessive CRC delimiter in the Acknowledge slot (ACK slot). At the end of a Data frame, after
the recessive ACK delimiter, comes the seven bit long and recessive EOF (End of Frame).
Data protection
The probability that corrupted CAN messages will remain
undetected is extraordinarily low. It is estimated to be 4.7 x
10-11 [2]. Responsible for this are error detection mechanisms defined in the CAN protocol. On the receiver side, besides the message-filter ing-independent CRC that is capable
Figure 4: Structure of the Data frame.
1/9
09.02.2010
of detecting up to five errors within a CAN message, checks

are also made of the format (Form Check) and bit stuff ing
rule (Stuff Check). The sender per forms bit monitor ing and
evaluates the ACK slot.
If one assumes an error rate of 10-3 in a CAN network, then
given an annual operating time of 1000 hours, a data rate of
500 KBit/s, a mean bus load of 25 percent and a mean message length of 80 bits, statistically speaking a corrupted CAN
message will remain undetected by the CAN protocol just
once every 4000 years. What is understood as the error rate
is the ratio of corrupted CAN messages to the number of all
transmitted CAN messages.
As soon as an error detection mechanism signals a transmission error, the CAN node detecting the error terminates message transmission by placing an error flag (six dominant
bits) on the CAN bus. The error flag intentionally violates the
bit stuff ing rule so that network-wide each CAN node perceives what until then was a local error and responds by terminating the message transmission, i.e. by appending an error flag. This method assures network-wide data consistency
which is so impor tant in distributed applications.
13:10 Uhr
Seite 1/10
Error correction consists of repetition of the aborted CAN

message by the same sender as soon as the CAN bus is free
again (after the error delimiter and ITM). In designing the
system it must be considered that the CSMA/CA bus access
method does not guarantee immediate repetition. The error
recovery time depends on the prior ity of the message and
the bus load.
Node monitor ing

Error signaling by error flag gives each CAN node the capability of terminating ongoing message transmissions. Since
this also applies to defective CAN nodes, such nodes are capable of bringing the entire CAN communication to a standstill. To prevent this each CAN node has network node monitor ing (Figure 5) that can disconnect (Bus off) a node found
to be defective based on error counters and rules for controlling the error counters.
Acknowledgment of received CAN messages

In a CAN network each message transmission is acknowledged simultaneously by all receivers in the ACK slot (in-frame acknowledgement), independent of message filter ing. A
dominant level signifies to a positive acknowledgment, and
a recessive level signifies a negative acknowledgment. Since
the sender places a recessive level in the ACK slot, just one
positive acknowledgment is suf ficient to confirm a correct
message transmission. Because of this node-neutral positive
acknowledgement, negatively acknowledging CAN nodes are
over written and remain unheard. Therefore they send an error flag after the ACK delimiter.
If not a single positive acknowledgment is received, that is
the ACK slot is not over written by any receiver, the sender
detects an ACK error and aborts the ongoing message transmission by sending an error flag.
Outlook
Figure 5:
Network node monitor ing using two er ror counters and
three node states.
1/10
Until just a few years ago CAN was the most sought after bus
technology in the automotive industry. The relentless electronification of the vehicle has caused CAN to encounter limits. Vehicle developers are questioning the suitability of the
CAN bus especially in bandwidth-intensive, real-time, critical
and highly safety-critical motor vehicle applications such as
09.02.2010
13:10 Uhr
Seite 1/11
the Lane Keeping Assistance driver assistance system, but

also in cost-sensitive convenience applications.
Therefore besides CAN two other bus technologies have become established over the course of time for use in the automobile or they are on an ideal course in that direction. We
are talking about LIN and FlexRay here. LIN (Local Interconnected Network) is already being used for cost-ef fective networking of sensors and actuators in the convenience area.
FlexRay is on the verge of being implemented in real-time
and safety-critical automotive applications due to its timetriggered communication method, a data rate of up to 20
MBit/sec and the possibility of sending over two communication channels. In its first production application worldwide
FlexRay will be implemented in an active suspension control
system on the new BMW X5.
ready been published at the Internet site of the Vector Academy [4].
Literature and Internet links:
[1] www.bosch.com
[2] Unruh, J., Mathony, H.J., Kaiser, K.H.: Error Detection Analysis of Automotive Communication Protocols, SAE International Congress 1990.
[3] www.vector-informatik.de
[4] www.vector-academy.de
[5] Mayer, E.: Ser ielle Bussysteme im Automobil Architektur, Aufgaben
und Vor teile [Serial bus systems in the automobile Architecture,
tasks and advantages]. Elektronik Automotive 7/2006, pp. 70ff.
Reliable ECU networking and data exchange

The specialists at Vector Informatik [3] support automotive
OEMs and suppliers, not only in CAN networking but also in
the LIN, FlexRay and MOST bus systems. For customer projects we of fer universal tool chains of design and development tools, optionally with software components and base
software for AUTOSAR control modules. These products are
supplemented by customer support, consulting services and
tools for process management in var ious application areas
that enable customized adaptations to specif ic requirements. These services are rounded out by a comprehensive
training program cover ing Vector tools, software components and serial bus systems.
For an introduction to ECU networking or data exchange in
the automobile the Stuttgart-based company of fers the oneday seminar Serial bus systems in the automobile. Fundamentals seminars on CAN, LIN, FlexRay and MOST convey the
basic knowledge needed to quickly gain familiar ity with the
many dif ferent development activities related to automotive
electronics [4].
The first part of this series of ar ticles [5] addressed serial
bus systems in the automobile in general terms. Upcoming
ar ticles three through five will discuss the LIN, FlexRay and
MOST serial bus systems. Interested readers will find supplemental and in-depth information on these topics that has al-
Author:
Eugen Mayer (Graduate Engineer with Technical Teaching Cer tif icate), after completing
his vocational training to become a communications technician, studied electronics at
the Technical College in Ravensburg/Weingar ten, Germany, and studied electrical
engineer ing and vocational teaching at the
University of Stuttgart. Since 1999 he has
been working at Vector Informatik where he
is employed as a Senior Trainer.
Tel. +49-711/80670-574, Fax +49-711/80670-111,
1/11
09.02.2010
13:08 Uhr
Seite 1

Part 3:
Simple and cost-ef fective data exchange in the

automobile with LIN
In just a very short time the LIN bus has established itself as the
technology of choice for simple and cost-ef fective data exchange
in the automobile. Today, many automotive OEMs are relying on
LIN to transmit non-critical signals in the body/convenience area.
The following ar ticle points out the reasons for the victory of LIN
(Local Interconnect Network) in the automobile and explains the
underlying technology.
Why another data bus in the automobile?

Growing demands of car users for driving conveniences have led to
wide-ranging electronification in this area of vehicle technology.
This is reflected in the migration of numerous electronic components into the convenience area. For a long time it was usual practice to interconnect the continuously increasing number of sensors,
actuators, stepper motors and DC motors directly to a central control module.
This trend gradually met with criticism: It led to a rapid increase in
wir ing costs, along with greater space requirements, increasing
weight and signif icantly greater susceptibility to faults. In addition, growing individualization required many dif ferent wire harness and connector var iants, which in turn made production, installation and maintenance considerably more dif ficult.
standard for the sensor/actuator area. With def inition of a simple

and cost-ef fective Physical Layer based on ISO standard 9141, as
well as a simple and lean communication protocol, the LIN Consor tium has laid the foundation for success. It set the stage for implementation of simple and cost-ef fective bus nodes.
The LIN Consor tium not only focused on LIN communication itself,
but also provided a development methodology (LIN Work Flow), and
this fur thered acceptance of the bus system in the automotive industry signif icantly. LIN Work Flow makes it is possible to automate
the development of a LIN network (LIN Cluster), with resulting time
and cost savings. The cornerstones of the development methodology are two data exchange formats used to describe the entire LIN
Cluster and individual LIN nodes uniformly (Figure 1).
Developers quickly recognized that networking of components over

a bus system would be an ideal solution in this automotive application domain too. However, since the CAN bus was not a candidate
for use in the cost-sensitive sensor/actuator area, many automotive
OEMs and suppliers began to develop their own sensor/actuator bus
systems as early as the mid-1990s.
This gradually resulted in the creation of numerous cost-ef fective
and simple yet proprietary sensor/actuator buses. In the year 2000
LIN arrived on the networking market as another serial bus system for the sensor/actuator area. This technology has prevailed on
a broad front, and LIN can now be found in nearly all vehicles, typically in convenience applications such as climate control, seat adjustment, door controls and mirror adjustment.
LIN Consor tium assists in breakthrough

An impor tant reason for the quick establishment of LIN was the
founding of the LIN Consor tium [1], which prominent automotive
OEMs and suppliers as well as semiconductor and tool manufacturers had joined. Its goal was to create a cross-OEM communication
1/12
Figure 1:
LIN Work Flow: The standardized and quick path to the
LIN Cluster.
Serving to describe an entire LIN Cluster are the uniform syntax

(LIN Configuration Language) and the standardized LIN Description File (LDF). Defined in the LDF are all of a LIN Clusters proper ties, in par ticular communication relationships. Generator tools
utilize the LDF to generate the software components needed for LIN
communication. Additionally, the LDF provides necessary information to analysis, measurement and testing tools and rest-of-bus
emulators.
Similarly, the description of individual LIN nodes (LIN Slaves) is
given structure by the uniform syntax of the Node Capability Language and standardized Node Capability Files (NCF). The NCF describes the per formance character istics of a LIN Slave (including
frame and signal def initions, bit rates, diagnostics) and in the framework of system design it represents the foundation for automated generation of the LDF.
The two date exchange formats and the configuration process defined in the LIN specification let users implement a LIN Slave type
(e.g. stepper motor) multiple times in a LIN Cluster or use a LIN Slave in dif ferent LIN Clusters (reusability of LIN Slaves).
Making just as impor tant a contribution to the success of LIN is detailed documentation of the specification. LIN specification 2.1
[2], in existence since November 2006, defines the Physical Layer,
communication protocol, LIN Work Flow, LIN API as well as diagnostics and configuration of the LIN nodes.
Single-wire communication at rates up to 20 KBit/sec

The goal of creating a low-cost communication protocol for serial
data exchange in the non-safety-critical sensor/actuator area primarily af fected the design of the Physical Layer. Physical signal
transmission in a LIN Cluster does not involve use of the dif ferential
signal transmission familiar from CAN, rather a conventional single-
09.02.2010
13:08 Uhr
Seite 2
wire line is used. To assure suf ficient noise immunity in spite of this
method, the supply voltage and ground of the ECU electronics are
used as reference voltages for the bus level. A LIN transceiver serves as the physical bus inter face. A level at least 40 % below the
supply voltage is interpreted by the receiver as a logical 0. Receivers interpret a level at least 60 % above the supply voltage as a
logical 1.
The maximum data rate is limited to 20 KBit/sec to keep noise emissions within limits. For line lengths up to 40 meters the maximum
recommended node count is 16. This takes into account the node
and line capacitances as well as the maximum allowable time constant of the LIN Cluster prescribed in the LIN specification.
In terms of circuit technology a LIN Cluster is equivalent to an Open
Collector circuit. A pull-up resistor ensures that the bus level remains nearly at the level of the supply voltage (High level) while
the Tx transistors of all LIN nodes are inhibited. The bus level is pulled to nearly ground level (Low level) as soon as one of the Tx transistors is enabled. Accordingly, the Low state is referred to as the
dominant level and the High state as the recessive level.
Master-Slave communication
Communication in a LIN Cluster is based on a Master-Slave architecture. A cluster consists of a Master node (LIN Master) and at least
one Slave node (LIN Slaves). For cost reasons, explicit communication controllers are not used. Instead LIN communication is implemented by software tasks in every node, the so-called Slave tasks.
The LIN Master also has a Master task that is used to coordinate
cluster communication (Figure 2).
Coordination is achieved by means of periodic execution of the LIN
Schedule that is organized in frame slots (Figure 3). At the begin-
Figure 2:
Master-Slave communication architecture:
All LIN nodes have a
Slave Task to par ticipate in communication in a LIN Cluster.
One LIN node also
has a Master Task for
controlling the LIN
communication.
1/13
09.02.2010
ning of each frame slot the Master Task transmits a frame header
with a Frame Identifier (ID), which all LIN Slaves evaluate in their
Slave Task. Immediately after the frame header a LIN Slave transmits the frame response associated with the ID. The LIN Frame,
consisting of the frame header and frame response, is available to
be received by every LIN node (Broadcasting) due to ID-based message addressing.
Data transmission by LIN frames

Due to the lack of a communication controller, serial data transmission in a LIN Cluster is handled over the microcontrollers serial inter face (Serial Communication Inter face - SCI) and is per formed
byte-by-byte. The SCI transmits each byte with the LSB (Least Signif icant Bit) first, and the byte is framed by a start bit and a stop
bit (SCI frame). That is, a LIN frame is composed of a combination
of a number of SCI frames distributed between the frame header
and frame response (Figure 4).
In transmitting the frame header the LIN Master per forms two key
communication tasks: It synchronizes the LIN Slaves and delegates
communication by assigning a sender and one or more receivers to
the frame response.
Due to cost sensitivity issues, the LIN Slaves may use on-chip resonators with a frequency tolerance of up to 14 percent. Therefore the
LIN Master transmits a Sync Break first to let all LIN Slaves know
that transmission of a LIN Frame is beginning. The Sync Break is
made up of at least 13 consecutive dominant bits, and it elicits a SCI
error from all LIN Slaves. It is terminated by the Sync Break Delimiter (at least one recessive bit). The LIN Master transmits the communication clock pulse with the subsequent Sync Byte (SCI Frame with
the value 0x55).
13:08 Uhr
Seite 3
An ID serves to delegate communication; it is six bits in length and

is protected by two par ity bits with even par ity and odd par ity. The
ID and two par ity bits together are referred to as the PID (Protected
Identifier). The first 60 IDs are available for useful data communication. The last four identifiers, ID 60 through 63, are reserved (of
which ID 60 and ID 61 are used for diagnostic purposes).
The frame response is composed of up to eight data bytes and a
checksum for error detection. A distinction is made between the
classic and extended checksum. The classic checksum is the inverted modulo-256 sum of all data bytes. There is a transmission error if
result of adding the modulo-256 sum to the arriving data bytes
does not equal 0xFF. The extended checksum also considers the
PID in forming the inverted modulo-256 sum.
Since the LIN Slaves are usually equipped with very simple and lowcost microcontrollers, not only are they allowed to delay transmission of the frame response a little (Response Space), but they may
also insert sending pause (Interbyte Spaces) between transmissions of SCI frames. Overall, this may lengthen the frame response
by 40 percent. The same applies to the frame header, primarily because there are dif ferent methods for generating the Sync Break. It
is absolutely essential to consider the 40 percent time reserve in
designing the LIN Schedule.
Sporadic, Event Triggered and Diagnostic Frames

The LIN specification contains provisions for making the communication cycle that is rigidly defined by the LIN Schedule more flexible and economical. The two frame types Sporadic Frame and
Event Triggered Frame are provided for this purpose. In introducing these supplemental frame types it has become common practice
to refer to the conventional LIN frame as an Unconditional Frame.
Figure 3:
Central message distribution
system: The LIN Master controls
sending and receiving of all LIN
frames by the Master Task and
LIN Schedule. A frame slot must
be long enough to transmit the
associated LIN frame. The length
of the IFS depends, among other
things, on the execution cycle
(time base) of the Master Task.
1/14
09.02.2010
13:08 Uhr
Seite 4
A Sporadic Frame is understood as an Unconditional Frame that

shares the same frame slot with other Unconditional Frames. Sporadic Frames are transmitted entirely by the LIN Master as necessary, so collisions are impossible. If the LIN Master has no need for
any of the frames, the associated frame slot simply remains empty.
The Event Triggered Frame was introduced to communicate sporadic
changes or events on the part of the LIN Slaves. It essentially corresponds to an Unconditional Frame, but with the dif ference that
multiple frame responses from dif ferent LIN Slaves are allocated to
the frame header. The frame response that is used to complete the
Event Triggered frame header depends on the needs of the related
LIN Slaves. There is a need when there are new data to be transported. The frame response of the Event Triggered Frame is identified by the PID of the associated Unconditional Frame in the first
byte.
In contrast to the Sporadic Frame, however, collisions cannot be
excluded in the Event Triggered Frame. In case of a collision the LIN
Master is responsible for transmission of all Unconditional Frames
assigned to the Event Triggered Frame. It does this by activating
and processing a Collision Resolving Schedule.
Both conventional Unconditional Frames and special Diagnostic
Frames are suitable for diagnosing the LIN Slaves. Unconditional
Frames are used for simple signal-based diagnostics, while Diagnostic Frames are used either for user-defined diagnostics or diagnostics based on a standardized transport protocol [3] and uniform
diagnostic services [4] [5].
The LIN specification defines two Diagnostic Frames: The Master
Request Frame and Slave Response Frame. The Master Request

Frame (ID=0x60) represents the Diagnostic Request. In this case
the LIN Master transmits both the frame header and the frame response. For example, a Master Request Frame is transmitted if there
is a Diagnostic Request via CAN. The Slave Response Frame
(ID=0x61) corresponds to the Diagnostic Response. In this case the
LIN Master transmits the header, and the specif ic LIN Slave transmits the response.
Management functions
The LIN specification defines Status Management and Network
Management. Status Management specifies that LIN Slaves must inform the LIN Master of transmission errors that are detected such
as par ity or checksum errors. This is done by a Response Error Signal in an Unconditional Frame (Status Frame); however this frame does not contain any fur ther information on the type of error.
The LIN specification does not define error handling rather it leaves
this task to the user.
The primary task of LIN Network Management is to regulate the
transition of all Slaves in a LIN Cluster from the normal communication state (Operational) to the Sleep state and in the other direction (Figure 5). If the LIN Slaves do not detect any bus activity for
four seconds, they switch from the Operational state to the Sleep
state. The same condition elicits a Sleep command from the LIN
Master, which is really a special Master Request Frame.
Conversely, when a LIN Slave detects a Wake Up Signal followed
by a valid header it switches from the Sleep state via the Initialization state to the Operational state. The Wake Up Signal consists of a
Figure 4:
Each LIN frame is composed of
a frame header and a frame
response. The frame header is
always sent by the LIN Master.
The frame response may be sent
by one LIN Slave or by the LIN
Master.
1/15
09.02.2010
dominant pulse minimum 250 microseconds and maximum 5 milliseconds in length, and it may be sent by any LIN node. The LIN
specification prescribes a maximum Initialization phase of 100 milliseconds, i.e. the LIN Master must begin to execute the LIN Schedule at the latest after this time span. If it remains passive the relevant LIN Slave sends another Wake Up Signal. The number of repetitions and the inter val between repetitions, as well as timeouts are
defined in the specification.
In case of networking issues: Quick resolution with external expertise

In networking with LIN, CAN, FlexRay and MOST, Vector Informatik
[6] supports automotive OEMs and suppliers with a universal tool
chain, embedded software components, base software for AUTOSAR
control modules and hardware inter faces. Users of the CANoe.LIN
tool for example benefit over the entire development process from
practice-proven functions for model generation, simulation, functional testing, conformity testing, diagnostics and analysis. Multibus design and maintenance of the communication data of a networked system is supported by DaVinci Network Designer for LIN,
CAN and FlexRay for example. Development, calibration and diagnostic tools for in-vehicle ECUs complete Vectors extensive product
line-up. Besides consultation the Stuttgart-based company also of fers a tool environment for the electronic systems development
process. These services are rounded out by a comprehensive training program cover ing Vector tools, software components and serial
bus systems.
For an entry-level introduction to serial data exchange in the automobile the Vector Academy [7] of fers the one-day training course
Serial bus systems in the automobile. Training courses on CAN,
Figure 5:
Communication state model of a LIN Slave.
1/16
13:08 Uhr
Seite 5
LIN, FlexRay and MOST fundamentals convey the necessary basic

knowledge needed to quickly become familiar with the wide variety
of development activities related to automotive electronics.
The first two parts of this series of ar ticles addressed the topics of
serial data exchange in the automobile and CAN. The next two ar ticles will discuss the serial bus systems FlexRay and MOST.
Literature and links:
[1] www.lin-subbus.org
[2] LIN Specification Package Revision 2.1
[3] Road vehicles Diagnostics on Controller Area Network (CAN) Part 2:
Network layer services, International Standard ISO 15765-2.4, Issue 4,
2002-06-21
[4] Road vehicles Diagnostics on controller area network (CAN) Part 3:
Implementation of diagnostic services, International Standard ISO
15765-3.5, Issue 5, 2002-12-12
[5] Road vehicles Diagnostic systems Part 1: Diagnostic services, International Standard ISO 14229-1.6, Issue 6, 2001-02-22
[6] www.vector-informatik.com
[7] www.vector-academy.com
Eugen Mayer
(Graduate Engineer with Technical Teaching
Cer tif icate), after completing his vocational
training to become a communications technician, studied electronics at the Technical
College in Ravensburg/Weingar ten, Germany, and studied electrical engineer ing and
vocational teaching at the University of
Stuttgart. Since 1999 he has been working at
Vector Informatik where he is employed as a
Senior Trainer.
Tel. +49-711/80670-574,
Fax +49-711/80670-111,
09.02.2010
13:08 Uhr
Seite 6
1/17
09.02.2010
13:09 Uhr
Seite 1
Network Development across LIN Bus Systems

Tools for Ef ficient Network Design
and Conformance Testing
The transition from the current LIN Version
2.0 to LIN 2.1, consistent LIN network
design and ef ficient test strategies
were key topics at the 3rd LIN Symposium
hosted by Vector Informatik GmbH in
February 2008 in Stuttgart.
Over 150 par ticipants from Germany and
across the globe learned about the
latest developments and trends related
to the LIN bus, and shared their
experiences on ef ficient use of simulation,
design and test tools.
Apart from minor changes and clar ifications, signif icant functional
improvements were made with the LIN 2.1 protocol version released
in November 2006 for event-triggered frames, Slave identification
and Slave configuration as well as for diagnostics over LIN users are
now awaiting the LIN consor tiums release of LIN 2.1 conformance
test specification in the second quar ter of 2008. This document
specifies tests for validating the conformance of LIN devices according to the dif ferent parts of the LIN 2.1 specification.
LIN Network Design

Prior to the development and test phases, many network design
challenges must first be mastered. These range from defining the
system topology and cycle times to creating LIN frames and schedule tables as well as routing relationships with other bus systems.
LIN communication design needs to be completely error-free and
consistent, since the resulting LIN Description File (LDF) is used for
all subsequent development steps: embedded software generation,
network analysis, conformance testing, system and integration
tests, etc. (Figure 1).
siderably simplifies the code development process. Since LIN supports only unsigned signals, globally defined signals must also be
unsigned. This limitation can usually be accepted by the CAN networks.
Without the appropriate tool support for network design, it is very
dif ficult to consider all design and quality requirements. Extensive
experience acquired dur ing series projects for var ious OEMs has
contributed to the success of version 2.0 of the DaVinci Network
Designer LIN (Figure 2). For example, initial schedule tables can be
automatically generated by simply defining the frame cycle times.
The schedule timings can then be easily optimized and refined depending on, for example, the per formance of each LIN Slave. The
design tool from Vector also helps the user to implement design
rules such as naming conventions for meaningful identifiers and
signal types as well as for uniform encoding of physical parameters.
The choice of network topology depends on var ious factors. For example, it may be possible to define a single LIN network rather than
separate networks for left and right door systems. In some cases, a
function-oriented approach is more appropriate, e.g. a dedicated
LIN network for climate control. It may also be necessary to make a
distinction between networks designed by the OEM and subsystems
developed completely by the OEMs supplier.
Ef ficient Design across Networks

Network design can be signif icantly simplified by directly routing
signals between networks. This requires defining unique signal
names for both CAN and LIN signals. Using this routing method, the
ECUs application code is relieved of routing tasks, which also con-
1/18
Figure 1:
Typical workflow for LIN network design
Design elements can be easily reused, and consistency checks are

automatically per formed. Especially impor tant for the ef ficient
network design across bus systems is the uniform management of
all signals in a global signal pool. DaVinci Network Designer is capable of importing existing network descriptions via standardized
data exchange formats such as LDF, NCF, DBC or FIBEX. This avoids
in many cases the re-enter ing of signal and encoding def initions.
From Multibus Tool to Data Backbone

A future trend is the increasing movement towards global network
design across CAN, LIN, MOST and FlexRay bus systems. The central
management of all data and information at the vehicle or model
level is becoming indispensable. Multibus design tools not only require access to a common, global signal pool, but must also support
multiple user access and rights. The eASEE Tool Suite from Vector
provides a data backbone that not only manages all engineer ing
data for network designs, but can also support the management of
project plans, storage of test data, coordinated data maintenance
or archiving of defined version states before delivery to partner
companies.
Test Strategies
09.02.2010
13:09 Uhr
Seite 2
used for simulation and ver ification are exclusively ECU external inter faces. White or gray box tests, on the other hand, always require
access to internal ECU inter faces. The Slave conformance test provided with the development and test tool CANoe.LIN (Figure 3) is
implemented almost entirely as a black box test. The Master conformance test, on the other hand, is implemented a gray box test
i.e. as a combination of black and white box test. A special test-LDF
and test application is required to stimulate the Master. The LIN bus
is used for ver ification.
Prototype of a Black Box Master Conformance Test

Although a gray box implementation allows the Master conformance test to be fully automated, it can only be applied a the start of
the V-model development process. This is mainly because the required test LDF and test application are not identical to real LDF
and application of the Master ECU. On request of an OEM, the LIN
specialists from Vector have specified a prototype black box Master
conformance test. By extending the Master driver to provide eleven test services, it was proved possible to per form the current
LIN2.0 Master conformance test dur ing all phases of development
using the real LDF and application. The Vector concept is not only
fundamentally extendable; it can also be easily standardized.
The primary method for guaranteeing the quality of LIN networks is

to apply the LIN conformance tests to each ECU. A black test implementation of such tests has the key advantage that the inter faces
Figure 2:
Design of the LIN Schedule with
DaVinci Network Designer LIN
1/19
09.02.2010
OEM-standardized LIN-Portfolio
Last year, Audi, BMW, Daimler, Porsche and VW created a document
for suppliers, which describes the requirements for the development of OEM-independent LIN portfolio. This document was first
presented to LIN consor tium members at the All-Members Meeting
in October 2007 and in February this year to the rest of the LIN
community at Vectors LIN Symposium. The main objective of this
initiative is to reduce development and production costs through
maximum reusability. The standardization of the physical layer requirements across dif ferent OEMs does not end with the choice of
transceiver, but must also include specifications for connectors, filter circuits, operating and installation conditions. A current example for such a LIN device, is an intelligent battery sensor developed
for several OEMs. A wiper motor and mirror adjuster are also in development. In order to increase the size of the LIN portfolio, each
OEM developing a LIN device in cooperation with a supplier, harmonizes the specifications with other OEMs in technical committees.
13:09 Uhr
Seite 3
Gavin C. Rogers
(B.Eng M.Sc.) is team leader and product
manager for LIN development and test tools.
Hans Quecke
(Information Technology degree) is team
leader and product manager for tools used
to design network architectures and communication data.
Figure 3:
Using the Slave Conformance Test
Module, LIN conformance tests can
be easily integrated into your own
CANoe test configurations.
1/20
09.02.2010
13:09 Uhr
Seite 4
Count on the worldwide leading

solution for LIN!
Vector has the comprehensive solution for every phase of your
professional LIN network development:
> Design your LIN networks systematically
> Simulate, analyze and test ECUs and entire networks
efficiently with CANoe and the XL-Interfaces
> Use our reliable LIN software components
> Make your ECUs and networks production-ready with
calibration, stress and logging tools from Vector
> Rely on our Vector service teams for development, training
and support
For successful projects, take advantage of proven tools,

scalable modules and over 20 years of networking expertise
at Vector!
Visit us at: www.lin-solutions.com

70499 Stuttgart
Tel. 07 11 / 8 06 70-0
N
he LI
y of t
a cop
w!
e
o
v
n
r
t
e
r
Res
Cha
ence
s.com
Refer
ution
o
s
n l
i
l
.
w
ww
09.02.2010
13:15 Uhr
Seite 1
Assur ing the Quality of LIN ECUs

Current and Future Strategies for
LIN Master Conformance Tests
High quality and reliability are essential preconditions
for the successful application of bus systems to modern
automobiles. Due to the signif icant increase in the
number of LIN (Local Interconnect Network) components used in automotive developments, ef ficient test
strategies for this cost-ef ficient bus system are gaining in impor tance. This ar ticle describes the current
possibilities for testing LIN nodes according to the
latest LIN conformance test specification. For
Master nodes a new and ef ficient black box test
strategy is presented based on the wellknown development and simulation tool
CANoe.LIN.
Introduction
The LIN consor tium provides in addition to the specifications for
each the protocol version corresponding conformance test specifications. The LIN conformance tests are used to ver ify whether a LIN
device is conform to a specif ic protocol version and also serve as a
basis for the LIN accreditation. Since LIN networks operate according to the Master-Slave principle, the protocol conformity of a Master node is of utmost impor tance. The LIN conformance tests are
specified separately for each OSI layer: physical layer, data link layer, network management and node configuration. Only application
layer tests need to be specified by the OEM or supplier.
Black box tests are best suited for the methodical implementation
of conformance tests, since they exclusively use a devices external
inter faces (e.g. LIN inter face) to stimulate and ver ify each test
case. White box tests on the other hand always require access to
a devices internal inter faces (e.g. the LIN drivers standardized
inter face). A LIN Master ECU of fers a very limited number of stimulation options via its external inter faces such as CAN. Gray box tests
that combine the two test methods are therefore the most commonly used method use to realize a LIN Master conformance test,
Figure 1.
Test Environment for LIN Conformance Tests

A typical ECU test case requires configuration and initialization
of the test system and ECU under test, as well as subsequent
stimulation and ver ification. The Slave conformance tests provided
with CANoe.LIN from Vector are implemented almost entirely as
black box tests. The tester in its role as LIN Master can usually
per form the stimulation and ver ification directly via the LIN bus.
Figure 1:
The LIN Master conformance
test is usually implemented as
a gray box test. A black box test
would, however, be preferable.
1/22
Only a few tests require manual stimulation or ver ification e.g. in

order to stimulate a wakeup signal. The Master conformance test,
on the other hand, is implemented by the Stuttgart-based tool
provider as a gray box. A special test LIN Description File (LDF) is
provided to ensure the correct configuration of the Master driver.
Together the generated driver code a special test application must
be downloaded to the Master under test. In this way, the LIN bus
can be used for both stimulation and ver ification purposes, despite
the testers role as LIN Slave.
The Delphi Technical Center in Krakau, Poland, has gained considerable experience with CANoe.LIN in the field of testing for both
LIN2.0 and J2602, the U.S. version of LIN. Since the LIN conformance tests do not cover the OSI application layer, Delphi TCK has
extended their test activities to cover var ious application tests. The
main focus of these tests is to test: signals, schedule tables, gateway routings, and diagnostics. The CAPL test functions provided
with CANoe.LIN have proved to be indispensable in implementing
and automating such tests. According to Delphi TCK even very complex test cases were easy to implement and extend using the C-like
CAPL syntax.
Disadvantages of Gray Box Master Tests

With respect to usability, a gray box implementation of the Master
conformance test has several disadvantages. For example it is not
possible to per form this test dur ing all phases of development.
Fur thermore, some preparation ef fort is involved, e.g. configuration
09.02.2010
13:15 Uhr
Seite 2
and generation of the Master driver code according to the test LDF,
before the Master-ECU can be tested.
The gray box Master conformance test allows the Master driver inter face to be indirectly accessed by the LIN-bus via a test application. Although full test coverage can be achieved in this way, this
approach means that the usual V-model development process cannot be strictly followed. For example, it is only possible to ver ify
the Masters conformity at the beginning of the development process. As soon as the productive database (LDF) and application are
running on the Master ECU, fur ther ver ifications can no longer be
easily per formed. Fur thermore, the OEM can not repeat the Master
conformance test without assistance from supplier.
The Way to a Black Box Master Test

Consequently, many automotive OEMs and suppliers of ten ask
whether the Master conformance test can be implemented as a
black box test. This would have the big advantage that OEMs and
suppliers could independently per form tests dur ing the entire development process with minimal configuration ef fort.
However, in order for a black box Master conformance test to have
genuine advantages over a gray box test, cer tain requirements
must be first met. Probably the most impor tant one is that the
same driver software used for development must also be used for
tests. One way of achieving this is to extend the LIN Master driver
with a special test inter face.
Figure 2:
The test communication required to realize a
Master conformance test as a black box test.
1/23
09.02.2010
This driver extension must permit the direct stimulation and ver ification of the Master under test via the LIN bus by providing the
tester with special test services, e.g. to change the schedule table
or read the drivers status word. The test communication over the
LIN bus between Master and tester can use a special diagnostic
service, comparable to those used for reconfiguration services.
A fur ther requirement on such a driver extension is of course the
minimal increase in ECU resources. The test inter face should also be
removable from the productive code, e.g. via a preprocessor define.
Prototype of a Black Box Test for LIN 2.x

The LIN specialists at Vector were requested by an OEM to design
and specify a black box Master conformance test. Dur ing specification of the prototype, it became quickly clear that the test communication must not negatively af fect the normal operation of the
Master-ECU. This can be only achieved by applying the standard LIN
diagnostics consisting of Master Requests and Slave Responses using a new special diagnostic service. Only in this case, it is the tester as Slave and not the Master who initiates communication. The
tester sends a test command to the Master-ECU, which can respond
either positively or negatively, Figure 2.
Before sending each test command it is necessary to execute a test
log-in and a test initialization. This raises the question to which extent a conformance test can be implemented independently of the
13:15 Uhr
Seite 3
Masters normal application. A completely independent and parallel

operation of both test and application proved to be impossible. The
application must therefore be involved in the realization.
There are basically two possible strategies for handling the interaction between the application and the drivers test mode, Figure 3.
One way is clearly inform the application that a test is being executed. An alternative method is to hide the test execution from the application as far as possible. Both strategies have their advantages
and disadvantages. The final choice of strategy may depend on the
feedback and wishes of Master-ECU suppliers. In both cases existing
drivers need to be extended to support the required test services.
The additional code required for the test-server functionality has
been estimated to be 2030 % of current LIN2.x drivers and can be
considered unproblematic for most Master ECU projects.
The current prototype implementation provides eleven services,
which is more than suf ficient to satisfy the LIN 2.0 Master conformance test, Figure 4. The proposed concept from Vector is not only
extendable, but can also be easily standardized, since it is based on
the existing LIN development process and protocol specifications.
Apart from these activities, Vector plans to fur ther develop
CANoe.LIN. For example, support of LIN 2.1 Slave tests is planned
for SP4/5 of Release 7.0 in the third quar ter of 2008, assuming that
Figure 3:
Two possible strategies for
the har monic interaction of
Master application and test
execution.
1/24
09.02.2010
13:15 Uhr
Seite 4
AS SUR ING THE QUAL I T Y OF LIN ECUS
the LIN 2.1 conformance test specifications are published in the

second quar ter of 2008. Support of the LIN 2.1 Master tests can be
expected with Release 7.1 of CANoe.LIN in the fourth quar ter of
2008. In addition to its development, analysis and simulations
tools, the Stuttgart-based company also provides training and
workshops related to all aspects of networking with CAN, LIN, MOST
and FlexRay. Through numerous customer projects, both OEMs and
suppliers also prof it directly from 20 years of networking experience and expertise at Vector.
Gavin C. Rogers
B.Eng M.Sc., is team leader and product
manager for LIN development and test tools.
Figure 4:
An over view of the 11 test
commands, which allow a complete coverage of the cur rent
LIN2.0 Master conformance
test.
1/25
09.02.2010
13:16 Uhr
Seite 1

Part 4:
FlexRay for data exchange in highly critical safety

applications
FlexRay is going into production for the first time. It will appear
on the BMW X5, which was presented to the public at the Par is
Auto Salon in August 2006, and it can be purchased in Germany
beginning in March of this year. Within its active chassis system,
FlexRay provides for secure and reliable data transmission between the central control module and the four satellite ECUs, one
located at each shock absorber. This ar ticle traces FlexRays path
into the automobile and explains the key principles of FlexRay bus
technology.
According to the German Federal Statistics Of fice [1] driving on

Germanys roads was never so safe as in the year 2005. Although
vehicle registrations grew considerably, there was a nearly one percent reduction in accidents involving personal injury (336619) compared to the prior year. There were also signif icant reductions in
the number of traf fic deaths (5361, -8.2%), serious injuries
(76952, -4.6%) and minor injuries (356491, -1 %). This trend was
continued in 2006: Between January and August, 3260 traf fic par ticipants were killed, and this represents a 7.8 percent reduction
compared to the prior year. The number of injured dropped by 5.8
percent over the same time period.
Decisive in lower ing the number of accidents and reducing the sever ity of accident outcomes are active safety systems and assistance systems that support drivers in their task of driving the vehicle. One study by a number of well-known automotive OEMs showed, for example, that ESP reduced the number of skidding accidents by up to 80 % [2]. Making just as impor tant a contribution to
reducing the sever ity of accident outcomes are increasingly safer
passenger cells and optimized restraint systems.
In light of the goal of halving traf fic fatalities by the year 2010, the
automotive industry is focusing on fur ther developing existing active safety systems and driver assistance systems and developing
new innovative systems. Since these systems not only provide information and instructions, but of ten also make corrective inter ventions and assume driving tasks, it is no longer possible to do
without electronic inter faces to the chassis and drivetrain. The
combination of brake-by-wire and steer-by-wire systems is thought
to have great potential.
1/26
mentations require very high data rates to transmit the increasing

number of control and status signals. They are signals that not only
need to be transmitted extremely quickly; their transmission also
needs to be absolutely deterministic.
That is the reason for the growing impor tance of communication
systems that guarantee fast and deterministic data transmission in
the automobile. Potential use of by-wire systems fur ther requires
the design of fault-tolerant structures and mechanisms. Although
by-wire systems may of fer wide-ranging capabilities and the benefits of increased design freedom, simplified assembly, personalization of the vehicle, etc., data transmission requirements in the automobile are elevated considerably, because these systems belong
to the class of fail-operational systems. They must continue to operate acceptably even when an error occurs.
CAN cannot satisfy these requires due to its event-driven and prior ity-driven bus access, its limited bandwidth of 500 KBit/sec based
on physical constraints in the automobile, and lack of fault-tolerant structures and mechanisms [3].
FlexRay The answer to heightened data transmission requirements in the automobile
Requirements of future data transmission in the automobile
The cer tainty that CAN could hardly be expected to satisfy growing
data transmission requirements in the automobile over the midterm, led to the development of a number of deterministic and
fault-tolerant serial bus systems with far greater data rates than
CAN. Examples include: TTP (Time Triggered Protocol) [4], Byteflight [5] and TTCAN (Time Triggered CAN) [6]. Although a development partnership was created as early as 2001 between Audi and
the TTP promoting company TTTech, and although Byteflight was
successfully applied to BMW 7-series cars in 2001, it is FlexRay that
has prevailed in the automotive industry.
Implementations of ever more challenging safety and driver-assistance functions go hand in hand with the increasingly more intensive integration of electronic ECUs in the automobile. These imple-
An impor tant reason for the success of FlexRay was the founding of
the FlexRay Consor tium [7], under whose auspices the two motor
09.02.2010
13:16 Uhr
Seite 2
vehicle manufacturers DaimlerChrysler and BMW and the two chip

producers Motorola and Philips joined forces in the year 2000.
Based on Byteflight bus technology originally developed by BMW,
the FlexRay Consor tium created the cross-OEM, deterministic and
fault-tolerant FlexRay communication standard with a data rate of
10 MBit/sec for extremely safety- and time-critical applications in
the automobile.
communication structure. However, the FlexRay nodes are not allowed uncontrolled bus access in response to application-related
events, as is the case in CAN. Rather they must conform to a precisely defined communication cycle that allocates a specif ic time
slot to each FlexRay message (Time Division Multiple Access - TDMA)
and thereby prescribes the send times of all FlexRay messages (Figure 1).
Today the FlexRay Consor tium is made up of seven core partners:

BMW, Bosch, DaimlerChrysler, Freescale, General Motors, Philips
and Volkswagen. Gradually, a number of Premium Associate Members (including Vector Informatik [8]) and Associate Members joined the organization.
Time-triggered communication not only ensures deterministic data

communication; it also ensures that all nodes of a FlexRay cluster
can be developed and tested independent of one another. In addition, removal or addition of FlexRay nodes in an existing cluster
must not impact the communication process; this is consistent with
the goal of re-use that is of ten pursued in automotive development.
Making a signif icant contribution to the success of FlexRay was the

detailed documentation of the FlexRay specification. The two most
impor tant specifications, the communication protocol and the
physical layer, are currently in Version 2.1. These and other FlexRay
bus technology specifications can be downloaded from the homepage of the FlexRay Consor tium [7].
FlexRay communication architecture Time-triggered,

fault tolerant and flexible
Just as in the case of data communication in a CAN cluster, data
communication in a FlexRay cluster is also based on a multi-master
Following the paradigms of time-triggered communication architectures, the underlying logic of FlexRay communication consists of
trigger ing all system activities when specif ic points are reached in
the time cycle. The network-wide synchronism of FlexRay nodes
that is necessary here, is assured by a distributed, fault-tolerant
clock synchronization mechanism: All FlexRay nodes not only continuously correct for the beginning times (offset correction) of regularly transmitted synchronization messages; they also correct for the
duration (slope correction) of the communication cycles (Figure 2).
Figure 1:
Principle of FlexRay
communication.
1/27
09.02.2010
This increases both the bandwidth ef ficiency and robustness of the

synchronization.
FlexRay communication can be based on either an electrical or optical physical layer. Speaking in favor of electrical signal transmission is its simplicity, which brings cost advantages. The comparatively cost-intensive optical signal transmission is character ized by
substantially better electromagnetic compatibility (EMC) compared
to electrical signal transmission.
FlexRay communication is not bound by a specif ic topology. A simple, passive bus structure is just as feasible as an active star topology or a combination of the two (Figure 3). The primary advantages
of the active star topology lie in possibility of disconnecting faulty
communication branches or FlexRay nodes and - in designing larger
clusters - the ability to terminate with ideal bus terminations when
physical signal transmission is electrical.
To minimize failure risk, FlexRay of fers redundant layout of the
communication channel (Figure 4). This redundant communication
channel could, on the other hand, be used to increase the data rate
to 20 Mbit/sec. The choice between fault tolerance and additional
bandwidth can be made individually for each FlexRay message.
Finally, an independent control mechanism (Bus Guardian) ensures
that a FlexRay node only gets access to the bus dur ing its turn in
the communication cycle. This prevents bus monopolization by a
defective FlexRay node (babbling idiot).
Figure 2:
Clock synchronization.
1/28
13:16 Uhr
Seite 3
FlexRay communication: Deterministic and dynamic

Each communication cycle is equal in length and is essentially organized into a static time segment and a dynamic time segment (Figure 1). Of central impor tance here is the static segment that begins
each communication cycle. It is subdivided into a user-definable
number (maximum 1023) of equally long static slots.
Each static slot is assigned to a FlexRay message to be sent by a
FlexRay node. Assignments of static slots, FlexRay messages and
FlexRay nodes are made by slot number, message identifier (ID),
and the value of the slot counter implemented on each FlexRay
node. To ensure that all FlexRay messages are transmitted at the
right time and in the correct sequence in each cycle, the slot counters on all FlexRay nodes are incremented synchronously at the beginning of each static slot. Because of its guaranteed equidistant
and therefore deterministic data transmission, the static segment
is predestined for the transmission of real-time relevant messages.
Following the static segment is an optional dynamic segment that
has the same length in every communication cycle. This segment is
also organized into slots, but not static slots, rather so-called minislots (Figure 1). Communication in the dynamic segment (minislotting) is also based on allocations and synchronous incrementing of the slot counters on the FlexRay nodes.
However, it is not mandatory to transmit the FlexRay messages associated to the minislots with each communication cycle, rather
they are only sent as needed. If messages are not needed, the slot
Figure 3:
Combined topology of passive bus and active star.
09.02.2010
13:16 Uhr
Seite 4
counter of a minislot is incremented after the defined time period.

While a (dynamic) FlexRay message is being transmitted, incrementing of the slot counter is delayed by the message transmission
time (Figure 5).
The allocation of a dynamic FlexRay message to a minislot implicitly
defines the prior ity of the FlexRay message: The lower the number
of the minislot, the higher the prior ity of the dynamic FlexRay message, the earlier it will be transmitted, and the higher the probability of transmission given a limited dynamic time segment length.
The dynamic FlexRay message assigned to the first minislot is always transmitted as necessary, provided that there is a suf ficiently
long dynamic time segment.
In the communication design it must be ensured that the lowest
prior ity dynamic FlexRay message can be transmitted too at least
provided that there are no other, higher prior ity needs. The designer of a FlexRay cluster must also ensure that transmission of the
longest dynamic FlexRay message is even possible. Other wise, the
communication design would not make any sense.
The communication cycle is completed by two additional time segments (Figure 1). The Symbol Window segment serves to check
the functionality of the Bus Guardian, and the Network Idle Time
NIT time segment closes the communication cycle. Dur ing the NIT
the FlexRay nodes calculate the correction factors needed to synchronize their local clocks. At the end of the NIT, an offset correction is made if necessary (the slope correction is always distributed
over the entire communication cycle). There is no data transmission
dur ing the NIT.
Figure 4:
Passive bus structure with two communication channels minimizes failure risk.
CRC-protected data transmission

The signals in a FlexRay cluster are transmitted by the well-defined
FlexRay message, wherein there is essentially no dif ference in the
formats of the FlexRay messages transmitted in the static segment
and those transmitted in the dynamic segment. They are each composed of a header, payload and trailer (Figure 6).
The header comprises the five-bit wide status field, ID, payload
length and cycle counter. The header-CRC (11 bits) protects parts of
the status field, ID and payload length with a Hamming distance of
6. The ID identifies the FlexRay message and represents a slot in
the static or dynamic segment. In the dynamic segment the ID corresponds to the prior ity of the FlexRay message. The individual bits
of the status field specify the FlexRay message more precisely. For
example, the sync frame indicator bit indicates whether the FlexRay message may be used for clock synchronization.
After the header comes the so-called payload. A total of up to 254
useful bytes may be transported by one FlexRay message. The trailer encompasses the header and payload-protecting CRC (24 bit).
Given a payload of up to 248 useful bytes, the CRC guarantees a
Hamming distance of 6. For a larger payload the Hamming distance
is 4 [8].
In networking issues: Achieving objectives rapidly with

external expertise
In the year 2001, Vector Informatik was already of fer ing the first
product solution for the development of FlexRay systems. In the
meantime, developers can now obtain a comprehensive portfolio of
products [9]. These include tools for designing, developing, simulating, analyzing, testing and calibrating ECUs and distributed networks. DaVinci Network Designer FlexRay gives the developer an
environment for ef ficiently designing network architecture and
communication relationships. Simulation, analysis and testing of
FlexRay systems are per formed with CANoe.FlexRay, whose multibus concept enables simultaneous operation of FlexRay, CAN, LIN
and MOST bus systems. For precise study of the FlexRay networks
system behavior in response to errors and disturbances, FRstress
generates them on a channel in the FlexRay cluster. For direct access to internal ECU var iables, the developer needs a special measurement and calibration protocol: XCP on FlexRay. In the context of
the development of the active chassis system on the new BMW X5,
BMW engineers implemented Vectors measurement, calibration
and diagnostic tool CANape. As the XCP-on-FlexRay Master, CANape
measures and calibrates individual ECU parameters directly via
FlexRay. Besides software, Vector also develops stacks for ECUs.
1/29
09.02.2010
FlexRay software components make it possible to interconnect applications with dif ferent bus or operating systems in an uncomplicated way. For hardware access to FlexRay buses, suitable bus inter faces connect to the USB, PCI and PCMCIA ports of a PC or notebook computer.
The Vector Academy [10] can teach the basic knowledge needed to
quickly become familiar with the diverse development activities related to ECU communication in the automobile. This knowledge is
shared in the context of seminars on CAN, LIN, FlexRay and MOST.
[1] www.destatis.de [2] www.bosch.com
[3] Mayer, E.: Datenkommunikation im Automobil Teil 2: Sicherer Datenaustausch mit CAN im Automobil [Data communication in the automobile Part 2: Reliable data exchange with CAN in the automobile]. In:
Elektronik Automotive 8/2006, pp. 34-37
[4] www.tttech.com [5] www.byteflight.com
[6] www.can-cia.org/can/ttcan [7] www.vector-informatik.com
[8] www.flexray.com [9] www.flexray-solutions.com
[10]www.vector-academy.com
13:17 Uhr
Seite 5
Eugen Mayer
(Graduate Engineer with Technical Teaching
Cer tif icate), after completing his vocational
training to become a communications technician, studied electronics at the Technical
College in Ravensburg/Weingar ten, Germany, and studied electrical engineer ing and
vocational teaching at the University of
Stuttgart. Since 1999 he has been working at
Vector Informatik where he is employed as a
Senior Trainer.
Tel. +49-711/80670-574,
Fax +49-711/80670-111,
Figure 5:
Example of communication flow in the dynamic time segment.
Figure 6:
Structure of the
FlexRay message with
header, payload and
trailer.
1/30
09.02.2010
13:17 Uhr
Seite 6
ECU
Calibration
Experience with series projects.
Choose proven FlexRay solutions.
Take advantage of our extensive experience with FlexRay series
projects. Use Vectors comprehensive product portfolio for your
FlexRay networking:
> Simulate, diagnose and test ECUs and networks with the
sophisticated development environment CANoe and the
FlexRay interfaces.
> Profit from standardized ECU software. Vector software
modules can be flexibly configured and easily integrated.
> Ensure advantages in both quality and time: Rely on professional
support during development and training.
Get FlexRay on the road - with series-proven tools, scalable
modules and 20 years of Vector networking know-how.
Get on board: www.flexray-solutions.com

70499 Stuttgart, Germany
Tel. +49 (0) 7 11 / 8 06 70-0
nce
efere
Ray R
x
e
l
F
he
now!
Get t
com
Char t
ions.
solut
y
a
r
.f le x
www
The Optimal Operating System for FlexRay-Based

Applications
FlexRay is either introduced for its deterministic behavior or for its quick data transfer, depending on the application.
Currently, its use in safety-related applications only plays a subordinate role. Criteria to be considered in the decision of
which operating system to use together with FlexRay, besides deterministic behavior and performance, include memory
protection and time monitoring. This article explains what is important in selecting the operating system and presents
specific solutions offered by Vector Informatik in the context of AUTOSAR.
> Interrupt Services Routines (ISRs) are hardware-specific and
are triggered by the hardware periphery. They have higher
priority than tasks and should therefore only be reserved
for subtasks requiring the fastest possible reaction time.
In a time-triggered operating system all processes and actions
under the control of the operating system are solely depending on
the time. For the application this results in strictly deterministic
time behavior.
AUTOSAR OS
Memory Protection
Global Time/
Synchronization
Time Monitoring
AUTOSAR has taken the OSEK-OS as a basis and extended it to

enable support of time-triggered functionalities. The specific properties of the AUTOSAR OS [2] are provided in four expansion stages,
the so-called Scalability Classes (SC). Table 1 shows a summary of
the relationship between these properties and the Scalability
Classes. Only properties relevant to a FlexRay-based application are
listed. These properties are explained in the following.
Schedule Tables
As a scalable high-speed communication system with deterministic

behavior, FlexRay is the right solution for use as a data backbone,
for distributed control systems or for safety-relevant applications
in the automotive area. In contrast to event-triggered CAN communication, all messages are assigned to fixed communication intervals. This offers to each participating ECU a cleary timed availability of its data. The design of a FlexRay network requires that certain
fundamental parameters be defined for all participating network
nodes in a very early phase of development. These parameters
include baudrate, cycle length, number and length of the slots in
the static and dynamic segments or macrotick duration. This scheduling of communication processes is mapped in the communication-specific software components, but it can also influence the
time structure of the application software.
The operating system (OS) coordinates the interplay of all participating software components. Both event-triggered and timetriggered operating systems are commercially available, each one
having different services. Another available option is operating
systems with memory protection.
Which operating system is best suited to a FlexRay-based application, and how should it be configured? In particular the question
arises of whether a time-triggered operating system is absolutely
necessary for synchronized FlexRay communication.
Fundamentals of event-triggered and time-triggered

operating systems
Scalabilty
Class
SC1
Event-triggered
Until now, event-triggered operating systems have usually been

used in the automotive area. The broadest acceptance is enjoyed by
the OSEK/VDX [1] OS, which in the future will also be available in
the form of an ISO standard. The goal of an operating system is to
provide, under optimal utilization of the hardware used, a supplemental run-time environment for managing functional units.
Defined operating system services offer this functionality. In
designing an application, at first time-independent, concurrent
subtasks are defined. The outcome of this are tasks or interrupts
compete for run-time assignment according to the operating systems scheduling algorithm:
> Tasks are triggered by alarms or events. A distinction is made
between Extended Tasks and Basic Tasks. Extended Tasks are
distinguished by their ability to wait for events.
SC2
Advanced development
of OSEKtime
SC3
Advanced development
of HIS-Protected OS
Comment
SC4
Table 1: FlexRay-relevant properties of the AUTOSAR OS
The currently available specifications of BSW (Basic Software) and
RTE (Runtime Environment) do not cover memory protection yet.
This will be addressed in future versions of the BSW and RTE
specifications.
1/32
07 Press Book_Seite_1-32_1-37.indd 2
09.02.2010 13:28:59 Uhr
Figure 1:
Case A Without error handling
Schedule Tables
The operating system manages multiple schedule tables. Each
schedule table consists of a list of defined time-based actions that
either activate tasks or send events to tasks.
budget, time monitoring guarantees lower-priority tasks or interrupts access to the processor to execute their tasks.
If an interrupt lasts too long, as in Case C of Figure 3, it is cancelled so that the extended task can continue to execute.
For each task:
For each interrupt:
Time monitoring
In a real-time system what is important is to process all tasks at the
right times. In the design phase sub-tasks are allocated fixed time
windows. To avoid delays at runtime a task may not tie up the CPU
longer than specified in the design. Therefore the operating system
monitors the execution time of each individual task and each interrupt. OSEKtime [3] provides classic deadline monitoring for this
purpose: Tasks must be completed before their assigned deadlines.
If a violation occurs, the overall system triggers a reset. This type
of monitoring is inadequate for extended tasks that can wait for
events. That is why the AUTOSAR-OS working group has defined
execution time monitoring for each individual task and each interrupt. This monitoring is defined by various parameters in the
configurator.
When a monitoring parameter is violated, depending on the configuration the operating system initiates a Reset_OS, Kill_Application, Kill_Task or Kill_Interrupt as a reaction to the error.
Figures 13 represent an AUTOSAR OS Scalability Class 2 with
time monitoring tasks and interrupts.
Figure 1 shows the the monitoring of an application consisting
of an extended task. The extended task is disrupted suspended
several times by an interrupt.
Due to a longer execution time of the extended task, e.g. for
handling Event 1 (Ev1), this may result in error handling, see Figure 2. This exclusively affects the originator. According to the
> Timeframe: Monitoring time > Timeframe: See Task

period (greater than the
> Worst case execution time per
execution time; it is not
execution
absolutely essential that the > Max. number of interrupts per
task be completed within the
Timeframe
monitoring time period; cf.
Figure 1 Case A).
> Execution time budget:
Worst case execution time per
monitoring time period.
If multiple activation of a Basic
Task should be allowed in the
operating systems configurator, the execution budget contains the total execution time
of all activations of the affected task. In principle multiple
activations are not possible for
extended tasks.
Multiple interrupts may be

allowed per Timeframe. However the worst case execution time
only refers to a single loop pass.
The effect of an additional
interrupt per Timeframe is
shown in cases B and C of figures 2 and 3.
1/33
09.02.2010 13:28:59 Uhr
Figure 2:
Case B With error handling caused
by excessively long execution time
of the task
Global Time/Synchronization Support

Distributed control systems requiring synchronization of tasks
beyond ECU boundaries need the support of a global time provided
to the operating system on a regular basis. An application may synchronize to the global time either:
> Stepwise, as soon as the global time is made available and
according to the maximum adaptation step from the
configuration (smooth), or
> By complete adaptation in one step (hard).
Memory Protection
Mechanisms for memory protection are necessary for early detection and prevention of disturbances by other modules. When
software modules from different producers are integrated in an ECU

the different software packets can be separated at runtime in terms
of their memory areas. A processor with hardware support is also
necessary. In addition, it should have a large memory and high
processing speed, since memory protection mechanisms slow down
operating system services by a factor of 1.5 to 2 on average.
Process of data exchange between FlexRay bus and

application
Any of the four AUTOSAR-OS properties presented may be selected,
and their costs and benefits must be weighed against one another
from a production implementation point of view. Thereby consideration must be given to the OS for optimal support of the synchronization of the data exchange between FlexRay and the application.
Figure 3:
Case C With error handling caused
by excessively long execution time
of an interrupt
1/34
09.02.2010 13:28:59 Uhr
THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS
In the FlexRay protocol up to 64 base cycles are combined to

form a continuously repeating round. Each base cycle contains
frames with different process data or signals for different application tasks. With its global time the FlexRay protocol provides the
foundation for synchronized data exchange. As soon as the data
network has been synchronized this global time is available to
every Communication Controller (CC) in the network.
In a distributed control system a function is distributed among
multiple ECUs in a network. The dead time caused by the signal
propagation time from the sending application to the receiving
application can have a decisive influence on the quality of control.
In principle, a small dead time has a beneficial effect.
In event-triggered communication systems the exchange of data
between CC and Host is essentially interrupt-driven, and accessing
to the bus may result under some conditions in wait times. The signal propagation time cannot be predicted precisely; therefore a
worst case estimate is typically made. Not until a network-global
time of the FlexRay protocol is made available can the operating
system offer services for synchronization to this time. Via the TDMA
(Time Division Multiple Access) method all participating ECUs are
aware of the precise point in time each message is sent or received
in the static area of the FlexRay cycle. These two properties minimize imprecision with regard to the signal propagation time of a
FlexRay-based application.
For synchronizing the exchange of data in a FlexRay-based application various methods of resolution are possible, depending on
the application needs and the availability of the operating system

properties. In principle, communication tasks should be triggered
by the CCs FlexRay timer. Activation of application tasks, on the
other hand, could be triggered by any desired timers. Four solution
approaches are explained in the following:
Solution A Alarms attached to the OS System Timer trigger the
application tasks.
At the beginning of each base cycle the FlexRay Cycle Start
Interrupt is triggered by the FlexRay controller. The communication task is activated immediately. Independently, the operating
system timer initiates the sequence of application tasks. Figure 4
shows a simplified form of this solution approach with just one
application and one communication task. It should be noted that
later triggering of a Cycle Start Interrupt, e.g. caused by drift
between the CC oscillator and the Host oscillator, results in delayed
processing of the transported FlexRay data (e.g. from frame 2) of
max. tOS = 1 ms. If the application does not expect a quicker reaction time, an OSEK-OS is sufficient.
Solution B If the control system requires a shorter response
time (less than 1 ms), triggering of the application task requires a
High Resolution Timer (resolution approx. 10 microseconds) with
the OSEK-OS. A suitable timer is then needed.
Solution C If the ECU does not have a High Resolution Timer,
the FlexRay timer can be additionally used to activate time-critical
application tasks. FlexRay-independent tasks can continue to be
attached to the OS System Timer.
Figure 4:
Solution A Data exchange between
FlexRay and an application task with
OSEK-OS
1/35
09.02.2010 13:29:00 Uhr
In startup behavior it should be noted that the FlexRay timer,

and consequently also the tasks that it activates, are unavailable
until the FlexRay controller has synchronized to the network for the
first time. If synchronization is lost afterwards, the FlexRay timer
can continue to operate based on its local time, provided that the
FlexRay controller was configured for this. An AUTOSAR OS of Scalability Class 1 with schedule tables is sufficient for this purpose.
This solution enables a control system distributed over multiple
ECUs, since the FlexRay global time assures synchronization
between all ECUs. This solution approach is depicted in Figure 5.
Solution D If in the above cases it is also necessary to monitor
the execution time of tasks and interrupts, an AUTOSAR OS SC2 or
SC4 is required. This prevents excessive execution times and
achieves time deterministic behavior.
Summary
A FlexRay-based application does not absolutely require a timetriggered operating system. The choice of a suitable operating system should be made individually for each ECU under consideration
of the application and architecture. For this purpose an analysis
pertaining to the synchronism among ECUs, safety requirements,
response time and time monitoring is necessary. Vector Informatik
offers the developer the optimal operating system for all FlexRay
applications: osCAN certified to the OSEK/VDX standard with or
without High Resolution Timer or osCAN AUTOSAR that covers Scalability Classes SC1-SC4 according to AUTOSAR OS V2.0. The Vector
FlexRay software components will operate together with any of
these OS variants. The osCAN TimingAnalyzer analyzes the schedulability of tasks from a worst-case perspective.
Vector supports the user with software components and individualized service for universal development of FlexRay systems up to
series production. Development is simplified by mature tools that
are tuned to one another, like for instance DaVinci Network Designer for all FlexRay-typical design tasks or CANoe.FlexRay 6.0 for simulation and stimulation of a network, integration tests and rest-ofbus simulation as well as analysis of the finished FlexRay network.
CANape 6.0 is used to access to all internal parameters of the
FlexRay ECU via the standardized measurement and XCP-on-FlexRay
calibration protocol. The FlexRay Evaluation Bundle provides for
quick and flexible implementation of a FlexRay network. This integrated environment of software components and tools also includes
a sample application for a FlexRay system with two nodes.
Figure 5:
Solution C Data exchange between
FlexRay hardware and an application
task with AUTOSAR SC1 OS
1/36
09.02.2010 13:29:00 Uhr
THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS
Literature references:
[1] OSEK/VDX Operating System, Version 2.2.2, www.osek-vdx.org
[2] AUTOSAR - Specification of Module Operating System V2.0,
www.autosar.org
[3 OSEKtime OSEK/VDX Time-Triggered Operating System, Version 1.0,
www.osek-vdx.org
Pascale Morizur (Graduate Engineer)

studied Physics/Electronics at the Grande
Ecole ICPI in Lyon (France). After graduating
in 1986 she worked for 10 years at MAN commercial vehicles in advanced development
for CAN, J1939 and diagnostics. She is
employed at Vector as a product management
engineer in the area of FlexRay embedded
software components.
Tel. +49-711/80670-2211,
Fax +49-711/80670-111,
E-mail: pascale.morizur@vector-informatik.de
Dirk Grossmann (Graduate Engineer)
studied Electrical Engineering at the University of Stuttgart. After graduating in 1997 he
worked first in the development of operating
systems at ETAS GmbH before assuming
responsibility for operating systems as North
American product manager for 2 years. Since
2003 he has been working at Vector as a
team leader responsible for the development
of FlexRay embedded software components.
Tel. +49-711/80670-223,
Fax +49-711/80670-111,
E-mail: dirk.grossmann@vector-informatik.de
Winfried Janz (Graduate Engineer)
studied Electrical Engineering at the University of Stuttgart. After working for 4 years
developing software for embedded controllers in control and automation engineering
he came to Vector in 1995. Since 1997 he has
been team leader and product manager
responsible for the development of OSEK
real-time operating systems. Through his
work in OSEK and AUTOSAR working committees he helped to give shape to the Operating
System and Configuration specifications.
Tel. +49-711/80670-367,
Fax +49-711/80670-111,
E-mail: winfried.janz@vector-informatik.de
1/37
09.02.2010 13:29:00 Uhr
Embedded Software for FlexRay Systems

Special aspects and benefits of implementing modularized software
Standardized software components will help in mastering the growing complexity of the interplay of all software components in an ECU. The ways in which todays ECU software should be developed for FlexRay were presented at the Vector
FlexRay Symposium in March of this year.
The FlexRay bus protocol is an in-vehicle network on its way to the
starting line providing large transmission bandwidth for fast control systems. FlexRay enables 20 times greater bandwidth than CAN
and reduces complexity by using fewer gateways. Because of its
time-triggered control, it is especially well suited as a communication system for distributed, fault-tolerant systems and safety-relevant applications. There is also the hope that the growing complexity of vehicle electronics can be kept in check by standardization of
the software system architecture with AUTOSAR.
What does FlexRay ECU software need to look like?

To fully exploit the advantages of FlexRay-based communication, it
makes sense to fundamentally develop the associated basic software according to the AUTOSAR specification. AUTOSAR specifies a
new development methodology, software architecture and basic
software. OEMs may gradually introduce it step-by-step on new
vehicle models. The standard-conformant ECU-specific software is

modularly structured (Figure 1). This enables partitioning of the
software components above the RTE and the basic software below
the RTE. The basic software has a modular internal structure and is
specified by clearly defined interfaces, so that software from any
source can be used in integration. In addition, the standard defines
which exchange formats can be used and how the interfaces
between individual modules need to operate.
This modularity makes it easier to scale software features to the
specific requirements of a vehicle variant or generation, e.g. ECUs
without network management. Development effort for the basic
software can be reduced for both OEMs and ECU suppliers because
the individual software modules can be delivered fully preconfigured by the software supplier. This lets developers place greater
focus on innovations and the actual development of functions than
was previously possible in development.
1/38
09.02.2010 13:25:59 Uhr
Embedded Architecture for FlexRay

The schematic layout of FlexRay basic software from Vector is
depicted in Figure 2. FlexRay-specific components such as the
interface, driver, network management (NM), and transport protocol (TP) are all contained in the FlexRay stack. The driver abstracts
the hardware, making it possible to service different communication controllers (CC). The driver initializes the controller, sends and
receives frames and detects controller errors. The interface communicates with the layers lying above it, processes PDUs (Protocol Data
Units) into frames and works in the reverse direction too. Moreover,
it issues send and receive acknowledgments to the affected layers.
Network management handles the coordination of all ECUs in the

cluster with regard to communication needs for the bus system. If
all of the bus nodes no longer have communication needs, the synchronous transition to the Bus Sleep ECU mode is initiated.
The FlexRay transport protocol is also placed on the FlexRay
interface. It handles the task of taking large data packets that cannot be sent in one PDU, breaking them down into segments, and
reassembling them on the receiving side.
Just how modular adaptation works in practice is demonstrated
by the example of two FlexRay drivers for a FlexRay controller from
Freescale and from NEC. The driver is optimally adapted to the specific hardware used and utilizes its existing features while still
Figure 1:
AUTOSAR layer model of ECU
software with modular structure.
Figure 2:
Schematic layout of FlexRay basic
software from Vector.
1/39
09.02.2010 13:26:00 Uhr
providing the layer above it with an unchanged view and mode of

behavior. In the case of the 16-bit S12X controller from Freescale,
the FlexRay driver must manage the buffer-RAM, since in this case
the necessary memory space must be swapped out to the systemRAM. The 32-bit NEC V850 controller already contains a large RAM
for the buffers in the FlexRay controller. This is where the driver
performs its efficient partitioning and utilization.
ECU calibration with XCP on FlexRay

It is even easy to integrate components developed at a later time in
the architecture, e.g. components that became necessary because
of new protocols or extended standards. These interfaces must also
conform to the AUTOSAR standard. For example, XCP functionality
might be added to the previously described FlexRay stack in order
to enable measurement and calibration of internal signals of the
FlexRay ECUs.
XCP is a universal communication protocol for optimizing the system parameters of an ECU. Due to the separation of protocol layer
and transport layer, XCP can be operated in various types of communication networks (XCP on CAN, FlexRay, Ethernet, USB, RS232
or SPI/SCI). The clear separation of layers is also reflected in the
integration in the FlexRay stack. The universal protocol layer XCP
lies above the FlexRay-specific transport layer (FrXCP), which in
turn enables signal exchange with the FlexRay interface (Figure 3).
Due to dynamic bandwidth allocation, the driver must handle the
additional task of buffer configuration during measurement or calibration. Therefore, this module is replaced by an extended version
of the standard AUTOSAR driver.
XCP is an address-oriented protocol. Communication takes place
between a controller component and a similarly structured software component in the XCP Master. Generally, the XCP Master is a
measurement and calibration tool (such as CANape from Vector)
that accesses measurement data in an address-oriented way, which

are then acquired task-synchronously (event driven) in the ECUs.
Dynamic bandwidth management

A connection is established via an initial communication channel
that is defined in the ECU description file (A2L). By transport layer
commands, the XCP Master controls allocation of available slots in
the dynamic section of a cycle and thereby enables channel extension for transmission of measurement and calibration data. This
load distribution is performed dynamically at runtime for optimal
bandwidth utilization. Since multiple ECUs communicate over the
same bus, a slot cannot be assigned exclusively; rather so-called
slot multiplexing makes it available to multiple ECUs. This makes
sense if less bandwidth is needed for a measurement, e.g. if an ECU
does not need to send a message each cycle. Each message gets a
unique address for this purpose (LPDU-Id, Data Link Layer Protocol
Data Unit Identifier), which describes the slot, cycle and channel.
This makes it possible to fill the same slot with data from a different ECU in each send cycle.
The measurement data are provided with a timestamp making it
possible to query measurement values at shorter intervals than the
cycle time. For example, a measurement may occur every 2.5 ms, even
if a system has a 5 ms cycle. It is only necessary to ensure that the
bandwidth is sufficient to transmit the data within a required time.
The ECU must reserve and dynamically configure transmission
and reception buffers by allocating RAM for this communication.
The RAM may be located in the controller or it may be necessary to
use external memory managed by the FlexRay driver.
Just how many slots are available for XCP and how slots should
be distributed must be defined early on namely during system
definition. This is done in the FIBEX file by also defining the slots
reserved for XCP. Various scenarios are possible here:
Figure 3:
Integration of XCP in the FlexRay
stack with clear separation of protocol layer (XCP) and transport layer
(FrXCP).
1/40
09.02.2010 13:26:01 Uhr
EMBEDDED SOFTWARE FOR FLEXRAY SYSTEMS
> Each ECU occupies its own slot

> Multiple ECUs utilize the same slot
> In this case each ECU has its own address (NAX, Node Address
for XCP). XCP transport layer commands are used to activate or
deactivate the buffer
> Buffers are configurable, which corresponds to dynamic
allocation
Regardless of the transport protocol used, the user interface of a
tool (XCP Master) should always represent the actual measurement
and calibration task adequately. Applications engineers can then
optimally tune ECU parameters independent of the bus system used
for communication.
The calibration engineer works with symbolic names, which allows
the parameters and measurement variables to be found in the ECU
without needing to know the encoded addresses of specific variables. The calibration tool uses the ECU description file to come up
with the link between the name and the physical address (Figure 4).
Dirk Gromann (Graduate Engineer)

studied electrical engineering at the University of Stuttgart. Since 2003 he has been
employed as team leader responsible for the
development of FlexRay embedded software
components at Vector.
Tel. +49-711/80670-223,
Fax +49-711/80670-111,
E-mail:
dirk.grossmann@vector-informatik.de
Oliver Kitt (Graduate Engineer)
studied physics at the University of Stuttgart. As team leader he is responsible for the
development of measurement and calibration protocols in CANape.
Tel. +49-711/80670-327,
Fax +49-711/80670-111,
E-mail: oliver.kitt@vector-informatik.de
Universal support in all development phases

The FlexRay developer gets universal support from the Vector company: From system description to implementation of the base software and calibration of the ECUs. This includes tools for design,
development, simulation, analysis, testing of ECUs, and distributed
networks and their bus interfaces. The first measurement, calibration and diagnostic tool to support XCP on FlexRay is CANape. With
ready-to-use software stacks for ECUs and XCP-on-FlexRay support
on the part of the calibration tool, the user gets components that
are perfectly coordinated with one another, are set up to be universal with AUTOSAR conformance, and can thereby be flexibly
implemented.
Figure 4:
XCP is implemented as a master/
slave structure. The XCP slave is
located in the ECU; the XCP Master is
located in the measurement and
calibration tool.
1/41
09.02.2010 13:26:01 Uhr
AUTOMOTIVE
FlexRay
2007
09.02.2010
SPECIAL
13:16 Uhr
EDITION
Seite 1
F L E X R AY
CANOE.FLEXRAY ENABLES ENGINEERS

T O S O LV E B O T H R O U T I N E A N D
CHALLENGING FLEXRAY TASKS
Becomes Daily Routine

M o re a n d m o re e n g i n e e rs a re n owa d ay s c o n f ro n t e d i n t h e i r d a i l y
j o b w i t h n ew c h a l l e n g e s a n d t o o l s re q u i re d by t h e i n t ro d u c t i o n o f
F l ex R ay a s a n ew b u s s y s t e m fo r a u t o m o t i ve a p p l i c at i o n s . Th i s a r t i c l e s h ow s h ow e n g i n e e rs s u c c e s s f u l l y m e e t t h e c h a l l e n g e s o f a n a l y z i n g , s i m u l at i n g , a n d t e s t i n g F l ex R ay E C U s a n d n e t wo rk s u s i n g
C A N o e . F l ex R ay f ro m Ve c t o r.
uring 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
1/42
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 FlexRay 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 Vectors
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
09.02.2010
13:16 Uhr
S P E C I A L E D I T I O N F L E X R AY
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.
Seite 2
AUTOMOTIVE
2007
l2
Figure 1: The FlexRay Frame Panel makes it easy to interactively send

FlexRay frames
ECU Test by Stimulation

The easiest way of testing an ECU is to
send frames interactively using CANoes FlexRay Frame
Panel. Using this integrated panel a FlexRay frames 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 signals 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
FlexRays 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?
automotive
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-theLoop) 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.
Figure 2: The Cluster Monitor for displaying the send conformity

of FlexRay nodes and their messages
automotive
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 (par1/43
AUTOMOTIVE
2007
09.02.2010
SPECIAL
13:16 Uhr
EDITION
Seite 3
F L E X R AY
Figure 3: CANoe RT is a real-time capable and deterministic execution platform

automotive
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.FlexRays 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 Vectors 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. Syn1/44
chronously 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 Vectors
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 Bke is Senior Software Development Engineer for the
Tools for Networks and Distributed
Systems product line.
Carl Hanser Verlag, Mnchen 2007. All rights including

reprinting, photographic reproduction and translation
reserved by the publishers.
09.02.2010
13:16 Uhr
Seite 4
Case Study
Testing FlexRay ECUs effectively and
reproducibly
The Customer
The Advantages
Bertrandt AG is one of Europes leading development partners in the automotive and aerospace industries. About
5500 employees at 30 business sites in Europe and in the
USA work on customized solutions ranging from individual components and modules to complete systems and
vehicles.
A high-performance and flexible environment for complex

ECU tests over the FlexRay bus
For conducting the simulation, Bertrandt uses CANoe.FlexRay
together with CANoe RT and the Real Time Rack to implement
a high-performance test system for FlexRay:
Testing an ECU with remaining bus simulation Testing
is already possible in early development phases without
requiring availability of real ECUs.
Using OEM-specific modules such as the Interaction Layer,
Transport Protocol, checksum calculation, etc. in the
remaining bus simulation Quick and easy implementation of the remaining bus simulation and standardized
execution of OEM-specific functions.
Execution of remaining bus simulation with CANoe RT
Simulation is characterized by deterministic execution,
short latency and quick response times.
Remaining bus simulation is executed exclusively on the
Real Time Rack No disturbance of the simulation by the
PCs operating system.
Real Time Rack is scalable Flexibly adaptable to future
test system requirements, e.g. number of FlexRay channels
or modification for other bus systems.
The Challenge
Testing FlexRay ECUs effectively and reproducibly
Proper behavior of FlexRay ECUs in normal operation and
under fault conditions is to be tested beginning in early
development phases. Test sequences of complex test cases
need to be executed, but it must also be possible to manually
start individual tests. The tests require a real-time capable
remaining bus simulation, to enable reliable statements
about the communication behavior of the ECU under test.
The Solution
ECU tests within a remaining bus simulation on a FlexRay
test bench
Bertrandt created a special test system to conduct reproducible testing of FlexRay ECUs. It contains a simulated vehicle
environment that is implemented with an extensive and realtime relevant remaining bus simulation. CANoe.FlexRay is
used here to simulate the remaining bus for the ECU under
test. To fulfill demanding real-time requirements, CANoe RT is
used to distribute CANoe.FlexRay functionality between two
computers. The simulation is executed on a high-performance
computer, the Real Time Rack. The configuration and user
interface run on the host computer of the test bench. The two
computers are interconnected via Ethernet.
We would be glad to provide you with an individual quotation:

sales@vector.com
www.vector.com
09.02.2010
FlexRay
13:12 Uhr
AUTOMOTIVE
Seite 1
2006
l1
To d e t e c t e r ro rs i n t h e
Sets the Pace
d e s i g n o f a F l ex R ay s y s t e m
or schedule it is important
t o s i m u l at e t h e s y s t e m e a r l y
i n t h e d eve l o p m e n t p ro c e s s . I n c h o o s i n g a s i m u l at i o n e n v i ro n m e n t
t h e F l ex R ay d eve l o p e r s e t s d e m a n d i n g re q u i re m e n t s o n s y s t e m c o m p o n e n t s t o p e r m i t re a l - t i m e s i m u l at i o n . Th i s a r t i c l e s h ow s h ow t h e s e
re q u i re m e n t s a re s at i s fi e d by a s i m u l at i o n p l at fo r m b a s e d o n t h e
b u s a n a l y s i s , t e s t i n g a n d s i m u l at i o n t o o l C A N o e . F l ex R ay.
1/46
o support the time-critical data transfer a FlexRay

simulation platform must be capable of generating periodic signals and messages at a high
cycle rate. Additional requirements include:
the support of multi-rate systems with different cycle
periods (Cycle Multiplexing)
constant and least possible jitter when activating and/or
executing application code
short response times between receiving and sending of
frames
permission of in-cycle responses.
communication controller should be automatically programmed with the parameters read out from the FIBEX
database. Automatic sending of FlexRay messages based
on schedule tables in the FIBEX database is an important
requirement, too.
The system should detect and report any synchronization
problems between the bus schedule and the application.
The simulation model may require synchronism implicitly.
In actual operation, however, this requirement may be
violated by interruptions, jitter or incorrect modeling
(Figure 1).
To achieve the desired deterministic time behavior, one of

the main focuses is to aim for the least possible overhead
of the operating system, communication stack and runtime environment.
In a simple but high-performance test system, ideally only
one simulation hardware (PC) and only one bus interface is
needed for real-time simulation of multiple FlexRay ECUs.
The limitations on TX and RX buffers like in real FlexRay
controllers should not exist here. Access to the FIBEX database format is essential so that users can utilize symbolic
signal and message names from a relevant database. The
Notification concept
The bus analysis, test and simulation tool CANoe.FlexRay
supports all mentioned requirements on remaining bus
simulations for FlexRay systems. In CANoe the notification
concept serves as the underlying architecture for executing
simulation models. For use with FlexRay it was specially
extended to include capability of synchronous notifications
at specific time points in the FlexRay cycle (Figure 2). That
is how actions can be executed regularly at the beginning
of the cycle or after a specific slot has ended. Of course,
notifications are also possible when frames are received or
AUTOMOTIVE
2006
09.02.2010
SPECIAL
Figure 1. Example of undersampling and oversampling

in an unsynchronized application
automotive
are missing. Any of the notifications may be limited to specific cycles (Cycle Multiplexing). The notification concept
implicitly assumes that the actions occur at the time points
named above.
Send requests are normally executed at the next possible
send time after notification. If this send time is no longer
achievable due to faulty modeling or interruptions, the
system instructs the user by an alarm indication. This enables detection of errors in the model or simulation platform
in very early modeling phases.
Support of the model
To simplify specification of model behavior, first of all the
capability was created for symbolically accessing signal
and message definitions in a FIBEX database; signals may
be interpreted and modified outside of the frame view.
Second, a buffer mechanism (Signal Layer) was implemented to enable reading and modification of signal values
at any time. CANoe.FlexRay automatically receives and
sends the associated FlexRay frames in background, whereby the send times are prescribed by the schedule in the
database.
13:12 Uhr
EDITION
Seite 2
F L E X R AY
CANoe offers the capability of specifying the behavior of

models in CAPL, a C-like programming language. The code
is not interpreted, rather it is executed directly on the
machine level. That makes CAPL especially predestined for
high real-time requirements and discrete models.
The software is also capable of simulating very complex
and quasi-continuous models. MATLAB/Simulink models
can also be linked directly to CANoe using a DLL generated by the CANoe internal Realtime Workshop and a special extension (Figure 3).
The data of different frames belonging to the same system
state must always be kept consistent. If at the time the
data is transferred to the TX buffer the send time of some
of the frames has already been exceeded, only some of the
messages can be sent correctly. The others will either be
missing or contain obsolete data from the previous cycle.
This problem is solved by CANoes strategy of transactionbased updating of multiple TX requests, in which either all
or none of the send updates of a cycle are executed.
Dedicated simulation environment
In simulating a model on hardware that is not real-time
capable and on a nondeterministic operating system, interruptions and delays may occur in notification and execution
under certain circumstances. This results in large and nondeterministic jitter when accessing the communication
medium. However such types of problems can generally
be minimized by deactivating certain system services and
applications that are not needed.
In projects with especially demanding real-time requirements, CANoe benefits from its dual-PC architecture (Figure 4). This is realized by two sub-applications which run on
different computers, so that real-time processing can be
separated from analysis and user control. The Soft RealTime Client handles user interactions and the analysis section, while the Real-Time Server is responsible for executing the models in real-time and interfacing to the bus
systems and other I/O interfaces. The Real-Time Server
may run on Windows XP Embedded, and Windows CE will
also be supported beginning in the first quarter of 2007. For
the most exacting real-time requirements Windows CE is
recommended together with special customized hardware, e.g. VN3300 from Vector Informatik. This combination is capable of task switching times less than 10 microseconds and response times of approx. 600 microseconds.
Figure 2. Examples of notification and activation time points in relation to the FlexRay schedule
automotive
1/47
09.02.2010
13:12 Uhr
Seite 3
AUTOMOTIVE
2006
l3
Summary
The presented real-time simulation system CANoe.FlexRay meets all requirements on a flexible and powerful
simulation system for a FlexRay bus. It decouples model
creation from the used execution platform, so that no adaptation effort is necessary. Its special simulation mechanisms and dual-PC architecture also make CANoe a convincing solution in projects with higher real-time requirements. All FlexRay solutions from Vector offer dedicated
and special features that support the special properties of
FlexRay systems optimally.
(All Figures: Vector Informatik GmbH)
Figure 3. MATLAB/Simulink support in CANoe

automotive
Dr. rer. nat. Carsten

Bke is Senior Software
Development Engineer
for the Tools for
Networks and
Distributed Systems
product line.
Carl Hanser Verlag, Mnchen 2007. All rights including

reprinting, photographic reproduction and translation
reserved by the publishers.
Figure 4. Dual-PC architecture of CANoe
automotive
The dual-PC architecture is fully transparent to the user,

since it handles all interactions and configuration tasks with
the Soft Real-Time Client. Ethernet is used to network the
two computers. The primary advantage of this highly optimized run-time environment is that the Real-Time Server is
responsible for 100 % of the bus load of the FlexRay cluster. Such a system is characterized by high update rates,
short response times and constantly small delays and jitter.
It enables simultaneous simulation of multiple ECU nodes,
executes the models precisely synchronous to the communication cycle and handles in-cycle responses. Of course, in simulations with lower real-time requirements
CANoe can also deliver excellent results on single-PC configurations under Windows 2000 or Windows XP.
Bus interfaces
For bus access the simulation systems need high-performance interfaces that can be obtained from Vector. The
VN3300 is a FlexRay interface for the PCI bus that is especially well-suited to real-time capable simulations. The
VN3600 connects the PC to FlexRay busses via USB and
is designed for typical bus analysis tasks. Both interfaces
can receive and/or send the maximum possible bus load
per cycle. There is no limitation on TX buffers.
1/48
09.02.2010
13:12 Uhr
Seite 4
1/49
09.02.2010
13:15 Uhr
Seite 1
Ef ficient Access to the FlexRay Bus

High-per formance FlexRay
Hardware for Analysis and
Simulation
PC inter faces for var ious standards are
indispensable tools in all development
phases of automotive electronics, wherever access is needed to what is happening on the bus. OEMs and suppliers are
being confronted with especially
complex challenges with the current
introduction of the FlexRay bus in first
production vehicles. Much more than on
the CAN bus, high per formance hardware
is a prerequisite for experiencing
reliable operation in all situations and
fully exploiting the potential of software
tools for simulation and analysis.
The var ious tasks of FlexRay development and associated tests require inter faces for both stationary PCs and mobile notebooks (Figure 1). In both cases, they need to satisfy special requirements for
simulation, analysis, calibration and testing. For example, an ECUs
standard controller recognizes when errors occur, but does not provide any information whatsoever on their causes. For a qualified
analysis, the developer needs besides the FlexRay messages and
signals themselves precise time stamps, comprehensive information and detailed itemization of all states on the bus and in the inter faces. Compared to previous automotive bus systems, technical
requirements for FlexRay are signif icantly more stringent. Since
FlexRays operation is not event-driven, but instead is time-triggered, it is necessary to synchronize all bus nodes. Send times are
precisely specified by the cyclic and synchronous time-division
multiplexing TDMA (Time Division Multiple Access) bus arbitration.
FlexRay Inter faces for all Requirements

A new generation of FlexRay inter faces delivers the right solutions
for all situations occurring in practice. In par ticular, one focus in
their development was a high level of assurance of future utility.
For example, updates to the FlexRay standard due to FPGA (Field
Programmable Gate Array) technology are fed-in by customers
themselves with driver updates.
On the one hand, behavior of the FlexRay inter faces from Vector
conforms to the standard; on the other, they are able to log all conceivable bus events due to their supplemental FPGA logic. They
record 100% of the bus traf fic of both FlexRay channels. The centerpiece an Intel PXA270 microcontroller together with 8 MByte
RAM is supported by the Bosch E-Ray and Fujitsu MB88121B
FlexRay communication controllers. Interchangeable as plug-in
modules, electrically isolated bus transceivers lend flexibility to
physical bus access with regard to future requirements.
Optimized for Analysis
Figure 1:
Hardware inter faces must also be implementable in
mobile FlexRay applications.
1/50
Overall, the inter faces were optimized for the best possible interaction with the simulation and analysis tools CANoe and CANalyzer,
and the measurement and calibration tool CANape (Figure 2). The
inter faces not only recognize all bus activities and buffer them as
necessary; rather they also pass all information to the host. Dif ferent than on controllers for ECUs, the controller host inter face is de-
signed to record all data, null and erroneous frames as well as symbols, including the associated timestamps and pass them on to the
software tools. This is the only way for developers to analyze,
meaningfully interpret and thereby systematically troubleshoot
sources of errors. If no FlexRay synchronization is established or no
FIBEX database is available with TDMA parameters, an asynchronous bus analysis is possible, in which it is only possible to follow
events and log them in reading operation. In this mode, it is also
possible to observe the star tup phase of a FlexRay network. The
measurement and calibration tool CANape gives developers the
ability to access internal ECU parameters via the standardized
XCP-on-FlexRay protocol. In this case, the FlexRay hardware supports resynchronization of the FlexRay inter face if bus traf fic has
been interrupted.
Maximum send Throughput for Simulations

The requirements demanded by ECU simulations on the PC, e.g. with
CANoe, are signif icantly greater than those for analysis mode. Since multiple ECUs can be simulated simultaneously on a suf ficiently
fast computer, the inter face must also be able to handle the higher
data throughput while taking all timing requirements into account.
Parallel simulation of ten or more ECUs is entirely realistic. It is
notewor thy that it only takes one of the new FlexRay inter faces to
09.02.2010
13:15 Uhr
Seite 2
achieve this. This per formance is enabled by the TX buffer that has
been extended to 2 MByte that can store over 1000 independent
send messages. Previous solutions typically only had an 8 KByte TX
buffer.
The CANoe RT platform is especially well-suited to small to mid-size
projects with real-time requirements, such as hardware-in-the-loop
simulations. It isolates visualization and control functions from the
real-time simulation. The simulation is executed troublefree on a
separate computer under Windows XP Embedded, and this guarantees reliable updates of send time points. The only inter face that
comes into consideration for this computer, called a RT Box or RT
Rack, is a fast PCI inter face such as the VN3300 (Figure 3).
For minimal response times and deterministic timing behavior of
the application, short latency times and minimal jitters are
absolutely essential. Besides the time required for the actual computations of the application, it is necessary to add the times for
transport processes through the dif ferent communication layers.
To achieve low PC loading despite this situation, DMA (Direct Memory Access) was implemented in the FlexRay hardware. DMA enables
high transmission rates and simultaneously relieves the main processor and gives it more time for computations. Latency times were
Figure 2:
Hardware inter faces for
the entire FlexRay tool
chain: Analysis, simulation, testing and software modules as well as
physical generation of
bus disturbances.
1/51
09.02.2010
optimized as was already done on CAN inter faces from Vector. The
shortest latency times are system-dependent and can be attained
with PCI inter faces.
Intelligent auxiliary Functions for everyday Work of

Developers
Experience and customer requirements on numerous FlexRay projects motivated developers at Vector to integrate a number of other
impor tant functions in the FlexRay inter faces: hardware support for
PDUs, automatically incrementing message counters, simulation of
inactive ECUs, group updates and autonomous bus start capability.
To decouple the transport layer from the applications, in the latest
FlexRay networks PDUs (Protocol Data Units) have been introduced,
instead of working directly with the relevant bus-specif ic data containers. Several such logical PDUs may lie within a FlexRay frame.
In this case, an additional piece of information is needed for each
PDU, indicating whether or not the contents are valid for the current cycle. One and the same PDU may also be defined in multiple
frames.
The PDU concept enhances flexibility and enables easy reuse of the
application, but its disadvantage is that considerably more ef fort is
required to generate and decode the FlexRay frames. Power ful
FlexRay inter faces compensate for this disadvantage by handling
Figure 3:
Stringent requirements are satisfied by the real-time
capable and deter ministic CANoe RT runtime platform.
1/52
13:15 Uhr
Seite 3
the multiplexing and demultiplexing of the PDUs into and out of

the frames on the hardware side.
Hardware-based incrementing of a payload area serves to reliably
simulate a senders heartbeat. That is because, if it is not possible
to guarantee this generation in a software-based simulation, the
receiver might reject the signal or even switch itself off. The intelligent hardware prevents this by repeatedly sending the old signal
values with counter incrementing, thereby reliably signaling that
the sending device is still alive.
Simulation of inactive ECUs enables later deletion and supplementing of frames to be sent, even if the user has not yet defined them
at star tup. The bus transceivers can be switched to inactive (Sleep
mode), after which wakeup patterns are still detected, however.
The bus transceivers can also actively execute a wakeup.
If data that belong together do not fit in a FlexRay slot, there is a
risk that it might not be possible to consistently transmit the data
in two frames of the same cycle. This is remedied by a group update, wherein the interrelated frames are always sent together.
To start up a FlexRay cluster, it is necessary to have at least two
Figure 4:
VN inter faces from Vector fulfill the strict bus inter face requirements imposed by the FlexRay bus. The USB
var iants VN3600/VN7600 are suitable for mobile applications, analyses and simple simulations. The PCI var iant VN3300 supports complex simulations of multiple
ECUs with real-time requirements.
09.02.2010
13:15 Uhr
Seite 4
EF FI CIENT AC CESS TO THE FLEX RAY BUS
ECUs that can execute a star tup. Some ECUs are not star tup-capable; they always integrate themselves in the communication after a
successful external star tup. If a network line only has these kinds
of devices for the measurement or simulation, the bus system cannot be started up due to the lack of star tup-capable nodes. Therefore, a second communication controller or star tup controller has
been integrated in all FlexRay inter faces.
In the area of FlexRay networking, Vector of fers a universal tool

chain, modular software modules as well as inter face hardware and
support for specif ic projects and a training program. The Stuttgartbased specialists activities as a Premium Associate Member of the
FlexRay Consor tium ensure that advanced developments and the
latest protocol specifications are always considered in the design of
tools and hardware inter faces.
Inter facing dedicated Applications with the Hardware

The new generation of FlexRay inter faces from Vector of fers highper formance hardware solutions for the most signif icant PC platforms and inter face types. These inter faces are specially tailored to
the requirements in simulation, analysis, calibration and testing
(Figure 4). The strengths of the USB var iants VN3600 and VN7600
lie in the mobile area. They are ideally suited to analysis and simple
simulations, while the VN3300 PCI card is intended for complex
simulations involving multiple ECUs under real-time constraints.
Currently, FlexRay buses are primarily used together with existing
CAN networks. The VN7600 FlexRay/CAN-USB inter face addresses
this situation appropriately with two FlexRay channels and three
CAN channels in one device. Developers of FlexRay/CAN applications benefit from simultaneous access to both bus systems in analyses and simulations with just one hardware module. The combined
hardware solution for FlexRay and CAN especially simplifies precise
synchronization of the dif ferent bus systems with highly precise
time stamps and a common time base. In this regard, a signif icantly
higher level of quality is achieved compared to multiple separate
solutions, since latencies must always be expected when USB is
used for inter facing.
A programming library of basic functions is supplied with the
FlexRay hardware. This makes it possible for dedicated applications
to access the Vector FlexRay hardware. The Advanced FlexRay Driver
Library is available for extended functions. The developer uses this
library to access extended functions of the inter faces, such as the
second communication controller, extended TX buffer and automatic payload increment.
Summary
FlexRay places dispropor tionately greater demands on hardware
and software than CAN or LIN networks, for example, due to its
time-triggered transmission method and considerably higher transmission rates. Here, the timing behavior of the hardware has a decisive influence on the quality of software services that can be provided. Signif icant per formance increases are realized by transferring software functions to the hardware.
Dr. Carsten Bke

studied Information Technology at the University of Paderborn. From 1995 to 2004, he
was employed as a scientif ic assistant at the
Heinz Nixdorf Institute in the area of Parallel
Systems Design. While there he was primarily
involved with automatic configuration of embedded communication systems. Since 2004
he has been employed as a Senior Software
Development Engineer at Vector Informatik
GmbH, where he develops tools for bus analysis and bus simulation of FlexRay systems.
Alfred Kless
studied Electrical Engineer ing at the Technical College of Esslingen. From 1991 to 2004,
he worked in the area of Test System Development at the company ALCATEL. Since
2004, he has held the position of Business
Development Manager at Vector Informatik
where he is responsible for the product lines
Network Inter faces and Measurement and
Calibration.
Mar tin Goner

studied Computer Engineer ing at the Technical College of Ulm. Since 1998, he has been
employed in the Network Inter faces area at
Vector Informatik GmbH. Since 2000, he has
been team leader for driver and firmware
development. As a product manager, he is
responsible for Vector FlexRay inter faces.
1/53
24
AUTOMOTIVE
2008
SPECIAL
EDITION
F L E X R AY
FLEXRAY TOOLS
S U C C E S S F U L LY S U P P O R T
DEVELOPMENTS WITH PDUBASED COMMUNICATIONS
AUTOSAR PDUs
Conquer FlexRay
Au d i i s u s i n g F l ex R ay i n t h e i r n ewe s t ve h i c l e s . Th e d eve l o p e d F l ex R ay n e t wo rk c o m m u n i c at i o n u s e s P D U s ( P ro t o c o l D at a U n i t s ) t h at
a re f u l l y AU TO S A R c o m p at i b l e . P D U s a re l o g i c a l d at a c o n t a i n e rs
fo r ex c h a n g i n g s i g n a l s b e t we e n a p p l i c at i o n s a n d a l l ow i n g g re at e r
d e c o u p l i n g f ro m t h e u n d e r l y i n g c o m m u n i c at i o n s y s t e m . Au d i b e n e fi t e d i m m e d i at e l y f ro m Ve c t o r s C A N o e a s a b u s a n a l y s i s a n d s i m u l at i o n t o o l w h i c h c a n n at i ve l y h a n d l e P D U s .
ith the release of the frame-oriented FIBEX

2.x database format, a new description semantic was needed to define PDU communications between network nodes. To overcome this gap,
Audi successfully developed the FIBEX+ description
semantic. Vector was able to immediately support
FIBEX+ in its tools. Profiting from their experiences
with FIBEX+, Audi introduced PDUs into the new FIBEX
3.0 standard from ASAM (Association for Standardisation of Automation and Measuring Systems [1]).
Continuous feedback from Audi enabled Vector engineers
to integrate important PDU features during the early phases
of tool development. Service Packs were delivered regularly to Audi, thus, allowing early testing of ECUs with PDU
communication stacks. Audi delivered their latest FIBEX+
database versions to Vector in order to ensure CANoes continuous compatibility. Close collaboration between Audi and
Vector accelerated the tool development and led to a professional analysis and development platform for FIBEX+ and
the new FIBEX 3.0 based FlexRay networks.
This article illustrates the impact PDUs have on the internal structure and features of a FlexRay development tool
CANoe.FlexRay and how Audi engineers benefit from
appropriate tool support.
1/54
09.02.2010 13:23:50 Uhr
PDU Layer for Network

Analysis
PDUs are managed by tools for analysis,
simulation, and test as high-level communication data containers (e.g. messages) containing signals. A FlexRay frame
can contain several PDUs. Since the layout of a frame can also change from cycle
to cycle, the same PDU can be mapped
to multiple frames. PDUs are uniquely
identifiable by their position in a FlexRay
frame in a specific slot during a specific
cycle. Vector identifies PDUs in CANoe
via the PDU Layer (Figure 1). The PDU
Layer introduces PDU objects and is located between the bus and the user interfaces, respectively. The layer is enabled
or disabled according to the assignment
of an appropriate database (FIBEX+ or
FIBEX 3.0) to CANoe. If the layer is enabled, then the complete symbolic database interpretation (PDU names, signals,
timings, etc.) of the network communication is performed at PDU level.
The PDUs main property, which is defined by the Update Bit, is decoupled from
the frames occurrence on the network.
Thus, frames on the network may contain
updated and non-updated PDUs at the
same time. Update Bit values can be visualized as pre-defined signals or can be
evaluated (e.g. in the graphics window,
see Figure 2). As a default for simple analysis or simulation received PDUs, which
have not been updated, are ignored. For a
detailed analysis, however, non-updated
PDUs can optionally be displayed and passed on to the simulated nodes. In addition, FlexRay frames including their payload can be displayed and received as socalled Raw Frames. Such PDU-based analysis features were heavily used by Audi
during their integration tests.
AUTOMOTIVE
2008
l 25
Figure 1: CANoes Architecture with Abstraction Layers for Signal and PDU Handling and Sending Behaviour (IL).
automotive
Figure 2: CANoes visualization of PDUs Update Bits in Graphics and Trace.

automotive
PDU Layer for Network

Simulation
Although the FlexRay protocol defines frames to be transmitted cyclically (even without any update), native PDUs
do not have this property. If a PDU is not updated, the receiver will normally not recognize the PDU. In order to trigger
the receiver cyclically, PDUs must be updated periodically.
If the automatic transmission of PDUs with the Update Bit
set (i.e. without any explicit data update) is required, then
the network designer can define these PDUs to have cyclic
timings. For this reason an Interaction Layer (see Figure 3)
on top of the PDU Layer was developed to handle those
constraints. As an extension to the FlexRay protocol, PDUs
may also be sent cyclically with (nearly) arbitrary periods
with set Update Bit (without being updated).
Message counters and check sums were defined by Audi

as additional but optional validity attributes of a PDU. In
fact, the Update Bits, message counters, and check sums
of a PDU are set independently from the application in
CANoe by the Interaction Layer in order to simplify the
remaining bus simulation. Thus, the engineer can concentrate on setting appropriate signal values. A further use
case is the insertion of explicit failures into the remaining
bus simulation in order to test an ECUs reaction. Therefore every automatic feature in CANoe can be disabled and
the Interaction Layer can be used for fault injection.
A simulation of communications with an ECU depends on
the occurrence of specific events (event-based simula1/55
09.02.2010 13:23:51 Uhr
26
AUTOMOTIVE
2008
SPECIAL
EDITION
F L E X R AY
Figure 3: The Interaction Layer (IL) of CANoe controls the sending behaviour of PDUs with set Update Bit inclusively
their extended validity attributes (message counter, user CRC).
automotive
tion). One of the most important events is the reception of

messages or changes in signal values from the bus. As
such, notification handlers for PDU reception and signal
changes are triggered by the PDU Layer.
Performance Aspects
The additional (but mandatory) PDU Layer does create
some overhead. When receiving FlexRay frames, PDUs
have to be extracted from the frame and then forwarded
to their notification handlers in the application. The same
PDU can be contained in different frames. Thus, a sort of
de-multiplexing of PDUs from frames is implemented by
the PDU Layer. These procedures are highly optimized.
On transmitting PDUs, they must be stored in the appropriate frame. The PDU can be located in different frames
according to the current (cycle) time or a different set of
PDUs may be contained in the frame. This results in a highly time-dependent multiplexed mapping of PDUs to FlexRay frames. If this is not fast enough, then frame slot misses should be expected. For maximum performance, Vector has implemented those functions to run on the hardware for the FlexRay bus interfaces of the VN series.
in CANoes Test Feature Set for PDUs. Additionally, for stimulus and response observations, PDUs can be sent interactively (PDU Panel) by implicitly manipulating signals
(Input Panels), higher level protocols (transport, diagnostics), or by a remaining bus simulation (CAPL, MATLAB
models, etc.).
Conclusion
PDU-based communications will not only be used in migration scenarios, e.g. when porting applications from CAN to
FlexRay networks, but also for new FlexRay developments. Audi has strongly influenced the development of
FIBEX 3.0 based on lessons learned with FIBEX+. Vectors experience with FIBEX+ allowed the quick support of
the new FIBEX 3.0 standard with CANoe. As communications become more complex and extensive, appropriate
modelling standards (i.e. FIBEX 3.0 and/or AUTOSAR), as
well as their professional tool support, are essential requirements for an efficient FlexRay development.
Literature:
[1] www.asam.org
Testing PDU-based Networks

Audi and its Tier1 suppliers also benefited from CANoes
AUTOSAR features. This includes a check for communication conformance in order to test the AUTOSAR communication stacks (especially the PDU Router) of the
ECUs. Here it is of great importance to be able to compare the real bus entities (Raw Frames) with the symbolic
interpretation (PDU abstraction level). This helped the Audi
engineers to identify in early phases an incorrect PDU or
Update Bit position in the raw FlexRay frames.
Tests can be split into two categories: First the applications transmission behaviour can be checked with respect to
updated PDUs and secondly, a signals integrity can be verified according to the application. Audis engineers have
successfully detected incorrect PDU update timings in
early development phases. These tests are fully supported
1/56
Dipl.-Ing. (FH) Wolfgang Brandsttter

is Hardware and Protocol Engineer for
FlexRay;
AUDI AG, 85045 Ingolstadt, Germany
Dr. rer. nat. Carsten Bke is Senior Software

Development Engineer for the Tools for Networks and Distributed Systems product line;
Vector Informatik GmbH, 70499 Stuttgart,
Germany
Carl Hanser Verlag, Mnchen 2009. All rights including reprinting,

photographic reproduction and translation reserved by the publishers.
09.02.2010 13:23:51 Uhr
1/57
09.02.2010 13:23:52 Uhr
22
AUTOMOTIVE
2009
Beyond
FlexRay
REQUIREMENTS ON A MODERN
DEVELOPMENT ENVIRONMENT
Th e F l ex R ay c o m m u n i c at i o n b u s a n d t h e F I B E X d at a b a s e ex c h a n g e fo r m at
re p re s e n t t h e c u r re n t s t at e - o f - t h e - a r t o f i n - ve h i c l e n e t wo rk i n g . I n t h i s
c o n t ex t , t h e F l ex R ay b u s m u s t f u l fi l re q u i re m e n t s re l at e d t o re m a i n i n g b u s
s i m u l at i o n , d i a g n o s t i c s a n d h i g h e r p ro t o c o l s , t e s t i n g a n d AU TO S A R d eve l o p m e n t m e t h o d o l o gy, ove r t h e e n t i re d eve l o p m e n t p ro c e s s .
hese requirements are fulfilled by FlexRay

development tools quickly and extensively,
sometimes in completely new ways. This
article discusses the requirements that need to be
met for an effective development platform. It
addresses special requirements of the FlexRay bus
for remaining bus simulations, higher-level protocols, diagnostics, highly specialized tests and
AUTOSAR development methodology.
Quick and reliable

simulation of ECUs
In the development process of an ECU, it is essential
to be able to operate the ECU before it is integrated in
the total system. The other ECUs of the FlexRay network must therefore be simulated as communication
partners. This is referred to as a remaining bus simulation. The strict time requirements associated with
FlexRay are very difficult to maintain; often simulations on the FlexRay bus are non-deterministic in their
execution. The resulting slot misses result in oversampling or undersampling of data on the bus. Therefore, it is often urgently recommended that these
simulations be executed on a dedicated, jitter-free and
deterministic (real-time capable) platform. Available
solutions include expensive HiL systems and difficult
Figure 1: CANoe RT is used to simulate

or test ECUs in real time.
automotive
1/58
09.02.2010 13:24:05 Uhr
AUTOMOTIVE
2009
l 23
to implement rapid prototyping

platforms. Nevertheless, there
is an effective and cost-saving
solution specifically designed
for remaining bus simulations in
testing: execution of the simulation on the hardware interfaces
of the bus simulation or analysis
tools being used. For example,
in the case of CANoe RT (figure
1), available on the high-end
interface VN89xx (mid 2010),
the user can run a simulation of
the total system in real-time, or
he uses a FlexRay interface
from Vector to execute the
simulation for one ECU. These
solutions are seamlessly integrated in the simulation and test
tool CANoe. This means that
developers can always use the
same platform and the same
code, regardless of whether
Figure 2: A powerful module concept is available for CANoe.FlexRay that lets
they are implementing a pure
users integrate additional protocols as well as application-specific and communisimulation or remaining bus
cative control of simulation behavior.
automotive
simulation, or whether they are
testing real ECUs on the bus.
The tools and platforms offer additional functions for a
used in dedicated programs or scripts via internal interfaremaining bus simulation as well. For example, the send
ces. This allows developers to influence and have an
behavior of ECUs is automatically modified (Interaction
access to communications by program control.
Layer) based on global system states (e.g. ignition on/off).
Alive counters are incremented and supplemental checkTesting by diagnostics
sums are already computed autonomously. This allows deAccess to an ECUs diagnostic functionality is very imporvelopers to focus fully on development or testing of the
tant, especially in early phases of the development proapplications of their ECUs. Naturally, in the case of testing it
cess, e.g. for reading out fault memory or for flashing. Since
is also possible to inject errors on the communication level.
diagnostics normally access an ECU via a CAN bus, a CANFlexRay gateway is needed for a FlexRay ECU. However,
such a gateway is generally unavailable in early developProtocols on higher layers
ment phases. That is why CANoes Diagnostic Feature Set
ECUs not only exchange signals such as vehicle speed and
oil temperature, they also communicate via protocols on
and the measurement and calibration tool CAN-ape support
higher layers of the ISO OSI model such as transport prodirect access to the diagnostic data over the FlexRay bus
tocols, network management protocols, in flashing or cali(figure 3). Special transport protocols for FlexRay (AUTObrating. During normal operation of the ECU, such protoSAR, ISO and OEM-specific variants) are supported in this
cols are needed to coordinate bus communication. In sercontext.
vice phases, the protocols are used to evaluate or update
After loading the diagnostic description databases in CANthe ECUs. The ECUs of a specific OEM each have their own
dela or ODX format, diagnostic dialogs and functions are
characteristics, e.g. of a transport protocol including OEMavailable in CANoe and CANape. For example, this allows
specific modifications. Modern development tools must
reading out the fault memory and displaying it including
not only be able to analyze or represent the basic data on
symbolic interpretation of the trouble codes. In addition,
the FlexRay bus based on the FIBEX description but also
the diagnostics console is used to symbolically send and
evaluate the mentioned protocols and transmitting inforevaluate all diagnostic requests, including their responses
mation through them. These functionalities are provided in
and parameters. Diagnostics communication is displayed
the form of add-ons or plug-ins (figure 2).
in its domain-specific notation in traces. A dedicated diaA modern modular approach to development tools enables
gnostics-API is also available, which enables easy access
re-use of plug-ins in different tools and seamless integrain programming, testing and tool control.
tion in the tool itself. Ideally, extensions are integrated as if
they were a native component of the tool. Protocol extenA simpler way to create ECU tests
sions provide special dialogs for setting and querying paraFrequently used standard tests often run according to the
meters of the protocols. The functions of plug-ins can be
same scheme. Therefore, a test tool should support fre1/59
09.02.2010 13:24:06 Uhr
24
AUTOMOTIVE
2009
quently recurring test patterns. For CANoe, it is very easy

to create sequential tests and test steps using the Test
Automation Editor. Prepared or user-specific libraries are
linked for this purpose; they allow the test engineer to
simply select and parameterize the test cases. Optionally,
complicated or high-effort tests can be specified algorithmically. This makes it possible to execute loops or branching based on the results of prior tests. Static and algorithmic tests may be combined.
Along with stimulation tests, the bus communication can
simultaneously be monitored regarding the FlexRay protocol. This includes detection of null frames and erroneous
frames as well as monitoring of the frame period, response time behavior etc. Monitoring activities are performed by so-called observational checks, which are already contained in CANoe and only need to be activated and
parameterized before use.
For Hardware-in-the-Loop or environment simulations, it is
frequently necessary to connect the ECU to its real sensors
and actuators. The digital and analogue input and output
variables must be provided or read-in. The VT System by
Vector was developed for this purpose and for open-loop
simulations and tests. It provides automotive-capable I/O
ports that can be integrated easily in tests. Unlike general
digital or analog I/O cards, the system can selectively
switch between connection of an original load or original
sensor or else a suitable simulation of the input or output.
At the same time, large voltage ranges and currents can be
handled by suitable signal conditioning. This also makes it
possible to simulate faulty behavior of a sensor or actuator
or a short circuit.
Testing AUTOSAR-functionality
in FlexRay systems
In the AUTOSAR design methodology, communication as
a basic service for the application is transparent. In the
framework of the overall system, communication is defined in the AUTOSAR System Description. If an AUTOSAR-ECU needs to be tested simply and quickly, the test
tool has to know the communication description for the
ECU. It is more user-friendly to directly read in the AUTOSAR System Description rather than the FIBEX databases. This will be supported by CANoe.FlexRay.
Key concepts in the AUTOSAR context are: Software
Components (SWCs), Runtime Environment (RTE) and
Virtual Functional Bus (VFB). Even if the ECU does not
physically exist yet, it must still be possible to test its Software Components. For this purpose, the DaVinci Component Tester is able to integrate the real ECUs code of a
SWC in the test environment. CANoe provides the RTE,
VFB and basic software. The test is executed with the wellknown functions of CANoe, including the automatic creation of a test report.
Figure 3: CANoe.FlexRay directly accesses the ECUs diagnostic

functions over the FlexRay bus.
automotive
systems require a powerful analyzing capability to test the

internal communication between the SWCs. Therefore,
the test tool needs access to the communication on the
VFB. This is usually done via XCP-on-FlexRay.
But especially extensive testing needs a higher performance. Therefore, the coupling of the control unit with the
test environment CANoe is done via a JTAG or Nexus
debug port. Only in this way parameters of the VFB, RTE
or basic software (BSW) of a real AUTOSAR ECU can be
read-in and calibrated quickly. This will be done by connecting the VFB of the real ECU to the test environment
CANoe. Thus, the testing and analyzing at the ECU-internal
interfaces of the SWCs can be done quite similarly in future, as today at the external control connections of an ECU.
If the requirements described are realized in a sophisticated way in the development tools and in the implementation of FlexRay systems, FlexRay networks can be developed more efficiently than CAN networks.
Outlook
In future, the number of AUTOSAR ECUs and the number
of included SWCs will grow rapidly. These complex
Dr. rer. nat. Carsten Bke is Senior Software

Development Engineer for the Tools for Networks and Distributed Systems product line
at Vector Informatik GmbH.

www.vector.com
Carl Hanser Verlag, Mnchen 2009. All rights including reprinting,

photographic reproduction and translation reserved by the publishers.
1/60
09.02.2010 13:24:06 Uhr
1/61
09.02.2010 13:24:07 Uhr
09.02.2010
13:04 Uhr
Seite 1

Part 5:
MOST for transmission of multimedia data

A premium class car is growing to resemble a mobile of fice.
In response to customer demand, increasing numbers of enter tainment and information media that are making their way into
automobiles. The most signif icant challenges in this area are,
first, to keep wir ing expense as low as possible, and second, to
fully satisfy the heightened functional requirements of an infotainment system in the car. As a result, the MOST (Media Oriented
System Transport) bus system is now used to transmit audio and
video signals in approx. 50 model series.
Electronics is responsible for a large number of innovative safety

and convenience functions in automotive technology. Experts predict that in just a few years electronics will represent a share of up
to 30 percent of vehicle value, and the worldwide market for electronics in cars will grow by approx. 6 percent annually to 230 billion
euros by the year 2015. The automotive industry is forecast to exhibit rapid growth rates, above all in the infotainment area, given
the continually increasing vehicle-kilometers on Germanys roads
(according to DIW [1] approx. 700 billion). The average citizen
spends about 270 hours in a car annually, whether it is on the way
to work, shopping or vacation.
Over the course of time, the car radio was supplemented by the CD
and MP3 player. This came to include CD changers and navigation
devices, and finally display screens also made their way into cars
for replaying DVD and video films. Moreover, hands-free Bluetooth
units with integrated microphones and iPod control are gradually
turning the cockpit a multimedia center, in which all of the play
lists and directories of a digital MP3 player can be displayed and
started directly on the in-vehicle display.
The already extensive wir ing cost and ef fort are increasing due to
continual growth in networking of continually higher per formance
infotainment devices of dimensions that can hardly be managed
any longer. For tunately, some automotive OEMs recognized the advantages that bus networking would also of fer in this area early on.
In the mid-1990s, BMW and Daimler began to develop a uniform
communication technology for serial transmission of audio and
video signals in the vehicle based on the D2B bus (Digital Data Bus)
developed by Matsushita and Philips.
MOST Cooperation
In 1998, BMW, Daimler, Harman/Becker and SMSC (formerly OASIS
SiliconSystems) founded the MOST Cooperation [2]. Since that time,
MOST has established itself as a de-facto standard for the transmission of multimedia data in the vehicle the MOST Cooperation is
made up of 15 international automotive OEMs and more than 70 device producers. The user organization laid the foundation for success
of the technology by defining an extensive specification. Version 2.5
of the MOST specification has been in existence since October 2006.
It is organized into the areas of Application, Network and Hardware.
Figure 1:
Structure of a MOST device that
among other things hosts the
Audio Disk Player functional
block. For system management,
the Net Block is mandatory for
each MOST device, and system
functions are mandatory for
each function block.
1/62
The Application area describes a logical device model based primarily on object-oriented methods, with the purpose of transparent modeling and control of distributed infotainment systems. Fur thermore, it defines a hierarchical communication model as well as
services for managing an infotainment system. The Network section describes the MOST Network Inter face Controller and its services, network management, and handling of data transport in a
MOST system. The Hardware section deals with aspects of the
hardware structure of a MOST device.
Functional modeling
A MOST device is subdivided into a functional level and a network
level (MOST Network Inter face). On the functional level, infotainment functionalities are embodied in so-called function blocks.
Each function block, e.g. the Audio Disk Player, provides the MOST
network with a dedicated set of functions, e.g. Track position,
that can be accessed by operation types such as Set for setting a
track or SetGet for setting and reading a track (Figure 1).
Functional addresses (FBlockID, FktID) are assigned to both the
function blocks and to the functions provided by a function block.
They can be taken from the so-called Function Catalog, as can the
identifiers of the operation types. For example, the Audio Disk
Player FBlock has FBlockID=0x31 and the Track Position function
has FktID=0x202.
The separation of function and network and functional modeling
make it possible to implement a functional communication model
that is fully independent of physical components (MOST devices).
Therefore, it does not matter which of the MOST devices is used to
contain a specif ic function.
09.02.2010
13:04 Uhr
Seite 2
commands are used for control communication. Their core components are the FBlockID, FktID, Operation Type and up to 65535 useful
bytes.
System management
The Application section defines higher-level function blocks and
functions for system management. System functions include the
FktIDs function (FktID=0x000) that is used to query the functions
supported by a function block, for example. The Notification system function (FktID=0x001), on the other hand, enables creation of
the notification matrix for a function block. Emerging from the
notification matrix is information on which MOST device should
be notified if a cer tain proper ty of a function block has changed.
This mechanism prevents an unnecessary increase in bus load in the
MOST system.
To query its function blocks and addresses, each MOST device has
the Net Block (system) function block with FBlockID=0x01. The
function blocks can learn about the function blocks implemented
on a MOST device using the FBlockIDs function (FktID=0x000). The
FktIDs 0x002, 0x003 and 0x004 are used to find the physical address, logical address and group address of a MOST device.
The Network Master plays an impor tant role in the management of a
MOST system. It is responsible for the system start and management of the Central Registry. This registry contains the logical
addresses of the MOST devices implemented in a MOST system and
the addresses of function blocks contained in the MOST devices.
Hierarchical communication model

MOST systems are patterned on a three-stage hierarchical control
philosophy based on the Master-Slave principle (Figure 2). Placed
at the uppermost hierarchical level is the HMI (Human Machine
Inter face), an exposed controller that provides the user with overall functionality. On the middle hierarchical level are the usual controllers. They cover part of the system functionality, and they share
their par tial system knowledge with the HMI as the System Master.
The lowermost hierarchical level is made up of the system slaves,
whose functions are used by one or more controllers. They are not
equipped with any system knowledge, and this substantially enhances their flexibility with regard to configuration. It is easy to
add system slaves or remove them from a MOST system. MOST
Figure 2:
Hierarchy of a MOST system
1/63
09.02.2010
13:04 Uhr
Seite 3
MOST Network Inter face

The MOST Network Inter face (Figure 3) ensures that the function
blocks housed on the var ious MOST devices are capable of real communication with one another. The MOST System Services (Low Level
System and MOST Network Services) provide the communication
functionalities needed to transport all multimedia relevant data
(time-continuous bit streams, packet data and control data). Low
Level System Services (Layer 2 services) are implemented in hardware (Network Inter face Controller NIC) and are placed over the
Physical Layer.
MOST Network Services, which encompass the Transport Layer in
the form of Basic Layer System Services and higher management in
the form of an application socket, are housed on an external Host
Controller (EHC) and control the NIC. It must be ensured that the
EHC can serve the time-critical parts of the Network Inter face. Over
time, with the progressive development of MOST technology from
MOST 25 to MOST 50 and MOST 150, this architecture has now encountered its limits.
In new developments, INIC (Intelligent Network Inter face Controller) replaces NIC. While INIC assumes control of execution of timecritical por tions of the network driver of the EHC, just a relatively
small part of the network driver still runs on the EHC, which essentially represents a socket for the application. The INIC architecture
thereby relieves the load of the EHC. For control, the INIC provides
the EHC or MOST API (MOST Network Services) with a functional inter face, the so-called INIC-API. The functions of the INIC are encapsulated in a function block (FBlock INIC).
MOST Networking
MOST technology enables transmission of continuous bit streams
(bit streaming) without buffer ing or unnecessary overhead. This involves having a specially designated MOST device (Timing Master)
feed the MOST frame (Figure 4) at a fixed frequency (44.1 KHz or 48
KHz) into the transmission medium, which is typically optical.
In a MOST25 system, the MOST frame provides 60 streaming channels at 8 bits (or 15 quadlets of 4 bytes each) for transmission of
continuous bit streams (source data area). The bandwidth of a streaming channel yields either 352.8 KBit/s (44.1 KHz) or 384 KBit/s
(48 KHz).
Since the MOST devices are physically interconnected into a ring,
each MOST frame must pass through every MOST device at the frequency prescribed by the Timing Master. As soon as the relevant
1/64
Figure 3:
Dif ference between NIC and INIC architectures in a
MOST device
communication partners (data source and sink) have connected to

the same streaming channel, bit streaming begins (Figure 5).
Connection or disconnection is usually made by a query by the function block Connection Master CM (FblockID=0x03). For this purpose, the CM provides the two functions BuildSyncConnection
and RemoveSyncConnection.
In the framework of building a connection, the CM requests that the
relevant data source, e.g. the TV tuner, have the suitable number of
streaming channels allocated by the Timing Master. That is because
the Timing Master is responsible for management of the channel
resource allocation table. The CM passes the addresses of the allocated streaming channels to the data sink, e.g. to the display, so
that it can connect to the streaming channels. Finally, the CM updates the sync connection table, which it uses to manage all synchronous connections. Disconnection is per formed according to the
same scheme.
To enable transmission of data packets, the user has the option of
reducing the number of streaming channels by up to 24 (six quadlets) using the Boundary Descriptor. All those streaming channels that are not reserved for bit streaming, are combined to form
the packet channel. While a maximum transmission rate of up to
12.7 MBit/s is possible at a frequency of 44.1 KHz, a maximum rate
09.02.2010
13:04 Uhr
Seite 4
Figure 4:
Layout of the MOST frame: Sent in
administrative byte 0 are synchronization infor mation and the
boundary descriptor, and in administrative byte 63 the status bits and
a par ity bit for protection of the
MOST frame.
of up to 13.8 MBit/s is attained at 48 KHz. The boundary descriptor

is managed by the Network Master function block (FBlockID=0x02).
It can be set via the Boundary function (FktId=0xA03).
A Layer 2 protocol is used to transmit data packets. The frame comprises the arbitration field, source and target address, data length
code, data field (either 48 or 1014 byte) and data protection. A
token circulating in the ring regulates bus access. The MOST device
that takes the token from the ring may access the packet channel.
Finally, the MOST system must transmit the MOST commands needed for management and control. Control messages (Figure 6) are
used here, which are transmitted on the control channel (2 bytes).
Therefore, 16 MOST frames (MOST block) are required to transmit a
control message. The bandwidth at 44.1 KHz is 705.6 KBit/s, and at
48 KHz it is 768 KBit/s. Transmission of control messages is also
based on a Layer 2 protocol. Bus access is implemented by the CSMA
method (Carrier Sense Multiple Access).
Figure 5:
Principle of bit streaming: The
Timing Master transmits MOST
frames at a frequency of 48 KHz.
40 streaming channels (10 quadlets)
are available for allocation, each
operating at 384 KBit/s (boundary
descriptor = 0xA). The packet
channel (20 bytes) provides a bandwidth of 7.68 MBit/s for the transmission of data packets.
1/65
09.02.2010
13:04 Uhr
Seite 5
Figure 6:
Control message. A MOST block is
required to transmit a control message. The control message is composed of: arbitration (a), target
address (b), source address (c),
message type (d), data field (e),
data protection (f), acknowledgment (g), and reser vation (h).
Physical Layer
Development, testing and analysis of MOST systems
Today, optical conductors of polymer fibers (POF polymer optical

fiber) are the state-of-the-art technology for transmitting audio
and video signals in the MOST system (Figure 7). Overall, the technical proper ties of polymer fibers are far superior to those of electrical transmission media. Especially notewor thy are its excellent
electromagnetic immunity and relatively high signal transmission
rate of up to 500 MBit/s. Fur thermore, the combination of POF, a
red light-emitting diode as the light source (wavelength 650 nm)
and a silicon PIN photodiode as the receiver represents a very economical and comparatively simple and manageable form of optical
signal transmission.
Vector Informatik GmbH has been an associate member of the MOST

Cooperation since 1999. Besides its extensive activities in the area
of serial bus systems such as CAN, FlexRay and LIN, the Stuttgartbased networking specialist has been supporting the development
and analysis of infotainment solutions in the automobile since the
year 2000. It of fers a comprehensive product lineup of analysis, development and test tools for applications such as high-end audio
systems, multimedia streaming, telephone and navigation. Hardware inter faces for bus access, a multibus data logger as well as
training courses and engineer ing and development services round
out its of fer ing [3]. The Vector Academy [4] supplies the necessary
basic knowledge related to ECU communication in the automobile
in the framework of seminars on CAN, LIN, FlexRay and MOST.
MOST 150, which follows MOST 50, is a MOST system that is current
ready to start. It is based on this sender and receiver technology
and of fers the user a transmission rate of 150 MBit/s. It can therefore handle the relatively short paths in the car of up to 20 meters
can without any problems.
1/66
09.02.2010
13:04 Uhr
Seite 6
Background knowledge on signal transmission in a MOST system via POF
When a light beam passes from one transparent medium to another, it is refracted. The greater the angle of incidence, the greater
the refraction. The medium in which the light beam forms a smaller
angle with the primary axis is the optically denser medium. In the
transition from the optically denser to the optically less

dense medium, the beam is refracted away from the primary axis. The angle of refraction a can be calculated if the
so-called indices of refraction n of the two media are known (Snellius Law). If the light beam exceeds an incidence
angle a0 in the transition from the optically denser medium to the optically less dense medium, then total reflection occurs.
This proper ty makes it possible to transport light in an optical conductor. In the MOST system, polymer fibers are
usually implemented for optical signal transmission, where
a core of PMMA (polymethylmethacrylate) is encased in a
thin sheath of fluor inated acrylate. PMMA has a larger refractive index than the fluor inated polymer. If the angle of
the incident light beam is greater than the limit angle,
then the light is conducted in the core due to total reflection.
The smallest attenuations for transmission of light in a
so-called step-index PMMA fiber are obtained at 520 nm
(green), 560 nm (yellow) and 650 nm (red). Red LEDs are
generally used (attenuation 0.14 dB/m), since they are
very inexpensive.
Figure 7:
Background knowledge on optical signal transmission in a MOST system

[1] www.diw.de
[2] www.mostcooperation.com
[3] www.vector-group.net/most/en
[4] www.vector-academy.com
Eugen Mayer
(Graduate engineer; technical teaching
certificate); after vocational training as a
communication electronics technician, he
studied electrical engineering and technical
education at the Technical College of Ravensburg/Weingarten and the University of
Stuttgart. Since 1999 he has been employed
at Vector Informatik where he works as a
Senior Trainer.
1/67
09.02.2010
13:08 Uhr
Seite 1
Ef ficient Testing in Automotive Electronics
One test environment from HIL simulation

to diagnostics
Testing cer tainly plays an impor tant role
in the automotive electronics development process today, but there is unexploited potential for more ef ficient and
automated testing execution in the
future by utilizing the right strategies,
ideas and tools. This ar ticle analyzes
the current state of the technology, clar ifies problematic interactions occurring
in practice, and demonstrates that tools
are already available today for solving
concrete project tasks related to testing
in an elegant and ef ficient way.
1 Introduction
Over the past ten years, the status of automotive electronics has
changed fundamentally. At the beginning, just a few ECUs were
used in the automobile but now more than 60 ECUs are being
installed in some luxury class cars. Additional electronic systems
offer improvements in the areas of safety, convenience and energysaving operation. Today, more innovations are based on electronics, and increasingly, a large share of this functionality is based upon software.
Growing complexity has made extensive and ef fective tests more
impor tant than ever before. The widespread use of numerous electronic components has caused the number of potential error sources to rise dispropor tionately. Tests are indispensable in all phases
of ECU development to detect and correct errors early, keeping
costs as low as possible. Some weaknesses of a total system do not
manifest themselves until components are integrated under actual
and real-time conditions. This has turned testing into a crossdepartmental and cross-manufacturer discipline.
The enormous electronic problems that occurred in initial years
have shown what happens when these facts are not considered and
systematic tests are neglected. The later that problems are identified in the development process, the more serious impact there is
to the increase in cost. This becomes clear in an extreme way when
correction of errors leads to costly recall actions after product has
been shipped. Par ticipants in the automotive industry have learned
their lessons and now attach great impor tance to the topic, but it is
possible to fur ther increase ef ficiency by consistent application of
available resources.
2/0
Costs for tests represent a considerable share of a project budget,

but proper functionality of the ECU must be assured. Therefore, it is
impor tant to achieve a maximum of test quality and test depth with
transparent concepts, e.g. by replacing insuf ficiently automated
test steps by modern methods and tools.
2 Tool for analysis, simulation and testing

The networking of ECUs represents the backbone of motor vehicle
electronics. In this context, the method of remaining bus simulation provides an impor tant foundation in per forming ECU tests.
Without at least a rudimentary simulation of the ECU environment,
most ECUs cannot be put into operation meaningfully. For example,
many ECUs only operate properly if they serve network management functions.
CANoe from Vector Informatik is a widely used tool for analyzing,
simulating and testing distributed, embedded systems (Figure 1).
It is used widely for remaining bus simulation and supports all
impor tant bus systems in par ticular CAN, LIN, MOST and FlexRay
for which Vector Informatik also supplies suitable PC inter faces.
Commercially available inter face cards can be used to address the
I/O lines of ECUs from CANoe. Moreover, Vector has announced
an I/O hardware product that supplements these general capabilities with test-specif ic functions such as switching additional loads
and short circuits directly to the ECU terminals.
09.02.2010
13:08 Uhr
Seite 3/1
Figure 1:
CANoe includes analysis, simulation
and test capabilities for networked
systems.
The var ious analysis capabilities, simulation components, and test

sequences rely on models integrated in the tool in the form of databases. These might be the communication matrices in DBC format
for CAN, FIBEX for FlexRay, XML function catalogs for MOST or LDF
files for LIN. Similarly, CDD and ODX descriptions may be used to
describe the diagnostic capabilities of an ECU. Besides containing
essential information on the system, test descriptions also contain
symbolic names for signals, messages, diagnostic services, etc. This
simplifies the work of the test user and test developer and creates an
abstraction layer between the test and communication description.
Any simple workstation PC running under Windows can be used to
run CANoe. More power ful test stations with improved real-time capabilities can be set up in a real-time configuration. This is done by
executing the remaining bus simulation and the actual test
execution on a dedicated computer running under a real-time
operating system (Windows CE), while a separate PC is used as the
graphical user inter face and for evaluation purposes (Figure 2).
In this setup, the system can also serve as a test execution environment for a component HIL tester.
Figure 2:
Dual-computer operation of CANoe Realtime of fers
improved real-time capabilities.
2/1
09.02.2010
3 Integration of testing and development

Todays development models call for tests in var ious phases of development (Figure 3). Generally, the individual tests are self-contained,
separate activities that are per formed by specialized personnel at
suitably equipped, dedicated workstations using special tools, languages and methods. In this context, test creation is of ten organized
as an independent task, detached from other development activities.
This segmented work approach results from distribution of the
many dif ferent tasks of the development process to specialized
working groups. However, if this separation of tasks is followed too
strictly, the numerous contact points between var ious development
and testing tasks will most likely not be utilized optimally. For example, only good coordination between component testing and
system testing can prevent expensive redundant development of
test cases that are identical in content. When compatible tools are
used, test cases that have already been developed once can be used
as a basis for other developments in var ious areas. This avoidance
of redundant developments frees up resources that could be used,
for example, to prof itably invest in the validation of existing test
cases and their advanced development. Comprehensive test management supplies a solid foundation for cooperation and, applying
the same resources, optimizes the depth and breadth of testing.
Coordination also helps to detect and fill gaps in testing.
Figure 3: Tests are indispensable in all phases of development.
2/2
13:08 Uhr
Seite 3/2
Besides linking the dif ferent test phases, development and test activities must also be interrelated and adapted to one another. Testing must be understood as an integral component of development
that requires comprehensive support using proper methods and
tools. This must be guaranteed in addition to the procedural and
organizational integration. What is impor tant here is to make tests
available in conjunction with development, not just in the required
formal ver ification phases. Ideally, it is possible to per form tests
directly at the ECU developers workstation with the resources existing there.
For this purpose, CANoe of fers a run-time environment for test
execution that can be used in parallel to the remaining bus simulation and analysis functions. The process is very easy to set up, especially if developers are already using CANoe for remaining bus simulation and analysis of bus communication.
CANoes test component enables manual, semiautomatic, and fully
automatic execution of tests. The developer can begin with simple
tests and later expand and complete them. In general, the process
of creating complex tests is a task of validation departments that
build their tests upon the developers tests.
An impor tant foundation for such tests is the remaining bus simulation, which ideally is not set up manually, but rather is automatically generated and parameter ized from the databases of the system
09.02.2010
13:08 Uhr
Seite 3/3
EF FI CIENT TEST ING IN AU TO MO TIVE ELEC TRON ICS
description. The actual work is per formed by so-called modeling

DLLs (e.g. Interaction Layer, Network Management, etc.), which
are supplied with the tool or which Vector puts together as OEMspecif ic modeling packets. The signals that the remaining bus simulation supplies to the simulated nodes may be acquired directly
from test scripts, or may be stimulated or added manually.
In contrast to the systematically planned, executed and documented activities of the test phases, formal execution and documentation are generally omitted in tests accompanying development.
Never theless, these tests make substantial contributions toward
overall quality, because they give the developer the ability to deliver a more stable product to the subsequent testing phase.
4 Matur ity level assessment and error analysis

To assess the matur ity level of an ECU dur ing development, a
comprehensive evaluation of all executed tests is necessary. The
quality of individual test results with regard to reliability and relevance must be considered, but more impor tant is broad coverage
of the required proper ties by suitable tests. Therefore, the results
of less formally executed tests are also helpful in matur ity analysis.
A prerequisite for this besides keeping records of test execution
is the consistent use of configuration management. This is also
indispensable from the perspective of achieving quality-oriented,

structured development processes.
A test record is produced whenever a test is executed using CANoe,
whether in the test laboratory or at a development workstation,
and is created without inter vention by the user or test case developer. It is then available for tests accompanying development
without requir ing additional ef fort. The XML format used for the
test records is an open format thus other tools can be used for fur ther processing of the results. For example, a test management
system might be used to evaluate the test records in the context of
a matur ity level analysis.
Essential in this ef fort is a mapping of test results to test cases,
and of test cases to requirements. This is easy to achieve by the use
of unique identifiers (e.g. a requirement ID), which the test case
developer references in individual test cases. CANoe automatically
copies this identifier to the test record so that all test cases, test
results and requirements are clearly interrelated (Figure 4).
At least as impor tant as recording and evaluating test results, is
the analysis of the causes of the errors that actually occur. Most
test tools do not provide any such capabilities or provide just rudimentary capabilities. One impor tant reason is that error analysis is
of ten considered as a completely independent task for developers.
Figure 4: Test cases and test results are clear ly referenced by IDs.
2/3
09.02.2010
First, they are faced with the problem of understanding errors detected in the test and tracing their causes. In par ticular, when errors are reported by test laboratories, the developer usually does
not even have access to the systems used in testing.
Therefore, at the test bench it is mandatory to precisely record the
test procedure and log every interaction with the DUT, especially
bus communication. Dur ing the role of analysis, CANoe enables
replay and analysis of any desired recordings (log records). It is
thus possible and beneficial to have the same type of test system at
the development workstation as that of the test bench, so that the
developer can reproduce error producing test cases independently.
In many cases it is possible to execute the relevant test cases even
if many simplifications are necessary, e.g. to avoid addressing nonexistent measurement hardware.
5 Signal abstraction and diagnostics

Abstraction is a commonly used and impor tant method for handling
complexity in software development and system design. This can also be applied to the handling of tests. Growing functionality in the
ECUs not only increases the complexity of systems, but also requires
tests that are more extensive and complex. The choice of the correct abstraction layer in composing tests not only af fects the ef fort
required to create test cases, and therefore costs, but also the quality of test cases. Like all other software components, the test cases
themselves may contain errors as well and should be checked before use. Another aspect is the necessary maintenance tasks, e.g.
making adaptations to modified requirements and correcting test
cases.
Abstraction on the signal level is a common way to test ECU functionality, and this is why in the ECU the actual application is generally based on a signal abstraction (Figure 5). In a CAN system, for
example, an Interaction Layer in the ECU provides the signal abstraction. That is exactly how CANoe uses an Interaction Layer; it
parameter izes itself from information contained in the network
descriptions, which also serve to create the ECU software. This
ensures that ECU and test environment utilize the same abstraction
layer and are therefore optimally tuned to one another.
Simultaneously, signal abstraction also represents at least on the
protocol level the remaining bus simulation. For example, it ensures that periodic signals are actually transmitted periodically. In
testing, the ECU is represented in a realistic environment regarding
bus communication. Moreover, when a change is made to the systems communication matrix, it is usually possible to continue to
use the test cases unmodified. With the same application, the abstraction enables reuse of test cases in similar projects.
In testing ECUs, it is not only the signal inter face that is impor tant.
2/4
13:08 Uhr
Seite 3/4
Many ECU functions can only be tested meaningfully if deeper

access to the ECU is possible. Such accesses are provided by the diagnostic and calibration inter faces, which are accessed via an ECUs
existing bus inter faces. It does not make sense to address these
inter faces by simple message sequences, since defined protocols
underlie the communication process. It is more convenient and
reliable to have appropriate abstractions for diagnostics and calibration.
In CANoe, either description files from the CANdela tool or ODX description files are responsible for parameter izing the diagnostic access layer. If no description is available for the actual diagnostic capabilities of an ECU, a gener ic description for KWP2000 and for UDS
supplied with CANoe may be used. Either the gener ic description or
a diagnostic description file customized for the ECU will of fer convenient access to the diagnostic services defined there. It is possible to obtain the same abstractions and advantages as in the signal
abstraction described above.
Figure 5:
Signals of fer an abstraction level between messages
and I/O connections on the one hand, and between test
def initions and simulation models on the other hand.
09.02.2010
13:08 Uhr
Seite 3/5
EF FI CIENT TEST ING IN AU TO MO TIVE ELEC TRON ICS
The CCP and XCP measurement and calibration protocols can be

used to access internal ECU var iables via test scripts in CANoe. The
measurement and calibration tool CANape handles these protocols
and the ECU description files (A2L) that are needed. CANoe controls
CANape via the COM inter face. This accomplishes the same goals as
in the signal and diagnostic abstraction described above.
6 Ef ficient test generation

A precise study of an ECUs test cases will reveal that many of the
test cases can be derived from just a few recurring patterns. This is
quite evident in gateway ECUs: A major ity of the test cases serve to
check the routing of signals and messages. Finally, the only reason
for the large number of test cases is the large number of possible
input and output data. But the same types of patterns are also
found in other types of ECUs. Expressed abstractly, this means that
many functions are tested by first putting the ECU in a specif ic state using a suitable stimulus and then checking the state that is reached. The recurring pattern of these test cases is: Set signals (stimulation), wait for the maximum allowable reaction time, and then
check the signals of the new ECU state. With some experience in
the use of test patterns, users will likely recognize a few additional
run-time patterns from which many test cases can be derived.
These patterns represent an oppor tunity for fur ther optimization of
test case generation. CANoe, in addition to of fer ing classic programming of test cases, also lets the user define test cases based
on test patterns. It is no longer necessary to program the pattern
contents, since the procedures are already known and permanently
integrated in the patterns that are supplied (Figure 6). Test case
generation is reduced to defining the target behavior, including
any supplemental data needed, such as the settling times to be toleranced.
To the extent that it is sensible, the supplied test patterns themselves are placed on the signal abstraction described above and enable symbolic access to signals, messages, etc., via the associated
databases. The use of diagnostic services or I/O signals is also possible. In short: The entire testing infrastructure of CANoe can be
used with test patterns. If there are requirements that extend
beyond these capabilities, the option of programming the test
cases still exists.
Automatic generation of test cases is another method for creating
tests ef ficiently, if suitable sources of information are available.
The contents of generated tests are by necessity limited to the description levels and depths of the sources. Never theless, generation of fers valuable support, primarily when it comes to cover ing
the formally defined basic proper ties of an ECU by tests. The relatively low ef fort required to generate test results in quicker availability thereby making it possible for earlier detection of undesirable
trends.
The tool chain from Vector utilizes such test generator approaches.
Description files such as the DBC database or CANdela def initions
are used as the source for the generator (Figure 7). The generator
uses them to generate test cases, which CANoe then executes. Since test scripts may make use of the entire tool infrastructure, the
test generators are of ten designed to be quite simple. For example,
Figure 6:
The use of patterns abstracts the actual execution of the test case and thereby simplifies test development.
2/5
09.02.2010
13:08 Uhr
Seite 3/6
Figure 7:
Test cases can be created from very dif ferent sources
using generators.
with just a little ef fort a generator can create suitable test cases
from a customer-specif ic gateway description (e.g. in the form of a
database or Excel spreadsheet). Thanks to the test patterns described above, this just requires a simple transformation of the customer-specif ic data into the format of the test patterns. Users can
create such a generator in a straightfor ward manner. Vector of fers
fur ther support in the form of project-related services.
7 Summary
The only way for automotive OEMs and suppliers to deal with the
growing requirements for ECU tests is by ef ficient test creation and
automatic test execution. The testing tool presented of fers a proven solution for implementing testing tasks with signal abstraction,
integration of diagnostic, calibration and I/O inter faces, the concept of test patterns, and test case generators. CANoe is a highper formance runtime environment for testing ECUs and networks.
The tool enables early creation and execution of tests with little ef fort, right at the developers workstation. The open inter faces of
CANoe facilitate seamless integration in a comprehensive testing
strategy and tool-supported test management. Although some users might still imagine it to be a futur istic vision, with suitable integration of CANoe it is already possible to determine matur ity levels
today. Vector is continuously developing CANoe for use in these
areas, thereby supporting users with a modern and ef ficient test
platform.
2/6
Thomas Riegraf (Graduate Engineer)

is Global Product Line Manager and
responsible for the product line Tools for
Networks and Distributed Systems
at Vector Informatik GmbH in Stuttgart.
Siegfried Beeh (Graduate Engineer)

is team leader and responsible for test tools,
diagnostics and modeling in CANoe
at Vector Informatik GmbH in Stuttgart.
Dipl.-Inform. Stefan Krau (Graduate in

Informatics) works as product manager
for test tools at Vector Informatik GmbH in
Stuttgart.
09.02.2010
13:08 Uhr
Seite 3/7
ECU Testing
Systemize your ECU test

XPSLPXT
ECU
Development
Distr. Systems
Diagnostics
ECU
Calibration
with systematic and reproducible tests. Efficient test systems

accelerate your CAN, LIN, MOST and FlexRay development.
> Create real test environments during the early stages of
development using generated simulations of a remaining bus.
> Use automatically created test cases and test reports for
systematic component and system tests.
> Speed up your ECU test by using the same platform for both
development and testing.
> Take advantage of the calibration, diagnostic or I/O port
interfaces in your tests.
> Test the full range of ECU functions with the VT System that
can simulate or control the environment.
ECU
Software
Vector tools and services help you achieve optimum test

quality and test coverage within all development phases.
Process
Management

70499 Stuttgart
Tel. +49 7 11 / 8 06 70-0
www.vector.com
Information and Downloads:

www.vector.com/ecu-test
ystem re
r VT S
a
Vecto
hardw
r test
m
la
s
u
y
d
s te
o
m/vtThe m
tor.co
c
e
v
.
www
09.02.2010
13:13 Uhr
Seite 1
Reliable Engineer ing Testing on a Wiper Motor Test Bench

Time-synchronous recording and evaluation of bus messages
and physical parameters dur ing endurance testing
Synchronizing the bus communication with measured physical parameters is one of the most dif ficult requirements for reliable tests of ECUs. The data from four data acquisition boards was evaluated in real-time and synchronized with the bus
communication of a control module in real-time. The specialists of Vector Informatik developed an individual solution based
on the development and test tool CANoe for the requirements of Valeo Wiper Systems.
Valeo Wiper System develops wiper modules using electric controlled reversing DC motors to realize complex wiper movements
based on the OEM customer specifications. The wiper system has to
react flexibly and intelligently to environmental conditions. This
can be realized with the use of a bus communication system. Additional features of reversing wiper motors are:
> Software-based wiper field control
> Alternating park position to prevent permanent set of the rubber
element
> Software control of wiper movement and other operating states
> Service position for the exchange of wiper blades
> Load-dependent speed control
> Overload protection
In order to validate the correct function of wiper motors controlled

by bus messages, Valeo needs to record and evaluate the physical
parameters such as angle, revolutions, and current on the test
bench. The determination and documentation of violations to customer specifications shall be rather simple and convenient. Valeo
engineers worked with dif ferent suppliers on var ious proposals for
the realization of such a test bench. Finally the concept of Vector
Informatik GmbH from Stuttgart, which is based on the flexible development and test software CANoe, was most convincing. A decisive factor for choosing Vector Informatik was Valeos experience in
the successful application of Vector tools such as CANalyzer, CANoe,
and CANister.
The CANoe Application Development team of Vector managed the
implementation. Through numerous test and simulation projects,
Unlike conventional fully rotating DC motors, the output shaft of

this motor type reverses at an angle less than 180 degrees. The motor drives a linkage that moves the wipers across the windshield.
In conformance with the vehicle architecture, Valeo uses a CAN or
LIN data bus to control the reversing wiper motor. This new wiper
system technology also requires new standards for testing technology, which needs to be developed in addition to the actual product.
Therefore, Valeo has derived the requirements for an endurance
test bench and test processes based on customer specifications:
> Test duration of more than 1.5 million wiping cycles which is
equal to a continuing test time of more than 28days.
> Automated, software-controlled test sequences
> The highest level of test system stability (software and hardware)
> The simultaneous testing of up to 5 motors using individual
control (voltage, motor loads, current limitation, etc.) including
the remaining bus simulation.
> Sequential measurement of physical motor parameters such as
angle, current, voltage, and temperature; calculation of speed
and RMS values
> Continuous monitor ing of bus communication, motor output
shaft movement profiles as well as other physical parameters and
their evaluation by compar ing actual measurements to envelop
curves.
> Control of the climate chamber according to specified climate
profiles
2/8
Figure 1:
Wiper test bench at Valeo
09.02.2010
13:13 Uhr
Seite 3/9
RE LI A BLE EN GI NEER ING TEST ING ON A WIP ER MO TOR TEST BENCH
the team has the necessary experience and know-how to create customer-specif ic test systems with CANoe. The Valeo test engineers
and the Vector team worked jointly to determine requirements for
the configuration inter face of the test process control. Both project
partners created the requirements for recording and evaluating
measurement data collectively. The development was initially based
on a simulated test environment prior to testing and adjusting the
CANoe test system on the actual Valeo test bench (Figure 1).
Customer-tailored hardware for recording measurement

data
The test bench hardware was build by the Gesellschaft fr Messund Systemtechnik (GMS) [Association for measur ing and system
technology] in Spaichingen, Germany. DAQ cards from National Instruments were used for recording analog and digital signals. The
parameters such as angles, currents, voltages, and torques are recorded for each test station individually. Vector integrated the four
data acquisition boards into the CANoe test system (Figure 2). For
standard applications this integration is realized using the CANoe
port link feature. At that time (before version 6.0), CANoe did not
support the signal block transfer between data recording board and
CANoe. Thus Vector developed a CAPL-DLL customized for the application, which expanded the CAPL programming language in CANoe
to include user-defined functions and inter faces.
This DLL is used to read and condition the measured signals directly
from the input buffer of the hardware. This allows nearly real-time
signal processing with a high sampling rate. Then these signals are
for warded to the data recording within CANoe (Figure 3). Parallel
to the data processing via the DAQ boards, the test bench control
activates the motors depending upon the test scenar ios using a
low-speed CAN bus or a LIN-1.3/2.0 bus.
Figure 2:
Integration of CANoe in the wiper test bench
In order to achieve the required test coverage, the test bench is

equipped with five individual stations, permitting independent operation. Each station is equipped with its own power supply, brake,
and bus inter face. The brake provides the load of the wiper motor
with a maximum torque of 15 Nm. The test engineer specifies the
individual load in the test setup.
The bus communication between each test specimen and the CANoe
control is also provided separately in order to simulate the communication character istics between the electric motor and the ECU as
realistically as possible. Vector created a remaining bus simulation
for the CAN or LIN bus communication for activating the wiper motor. Since there was not a real wiper ECU at the beginning of the
project, the remaining bus simulation was expanded by an additional node that simulated the character istics of the wiper motor.
After the integration of the real ECU, this node was simply deactivated.
The test bench is equipped with a standard industrial PC for the
simulation and control functions as well as for the evaluation of the
measured signals in parallel for all five test stations. The PC is also
responsible for activating the wiper motors via the CAN or LIN buses. A CANcardXL and two CANboardXL with the appropriate CANcabs
or LINcabs from Vector are used as inter face for the bus inter face.
Permanent set point/actual compar isons make the

evaluation easier
The test sequences of an endurance test are customer specif ic and
include all functions of the wiper motor. For example, an endurance
test might last more than 1200 hours. The wiper motor is operated
at dif ferent loads and temperatures in all modes such as high and
low speed, inter val mode, off and sleep mode.
Figure 3:
Data evaluation in the CANoe node layer DLL
2/9
09.02.2010
Dur ing these tests, the monitored physical parameters such as current, rotation angle, the position of the motor output shaft, and
motor temperature are allowed to vary within specif ic limits only.
The limits are specified as envelope curves (Figure 4). In order to
achieve the required accuracy for example of the RMS value of the
current, the data is recorded with a sampling rate of up to 20 kHz.
Post processing of the raw data reduces the data to one single value
within 2 ms.
A part of the evaluation is the permanent compar ison between the
measured signals and the specified envelope curve. The data is
temporarily stored in a ring buffer. In case of deviations, CANoe
stores pre and post event data values (logging). The data volume is
adjustable (Figure 5). The Vector software application is able to
record real time bus communication between the motor control and
the wiper motor in parallel to the measured signals. If communication errors occur, the CANoe logging function records the measured
physical parameters as well as the corresponding bus communication, including the pre and post event data.
13:13 Uhr
Seite 3/10
Synchronous recording of the bus communication with the physical

measurement values already mentioned above is the critical factor
in achieving the most useful test results. It has shown to be especially favorable that the recording of the bus communication, the
measurement recording and the control of the test bench be done
by a single software tool with a common time basis (CANoe).
CANoe is also responsible for compar ing the measured physical parameters and the bus communication with the specified limits. If
critical events occur the results are recorded. I.e. if defined limits
are exceeded or if switch-off criteria are reached. The latter is also
used to switch off the test.
The clear operating structure simplifies test configuration

According to the specification of Valeo the Vector team also developed a CANoe user inter face to create var ious test sequences, visualizations (Figure 6) and for the test bench control. The operatorfriendly user inter face allows the test engineers to create complex
test procedures and test sequences, based on time, event, or cycle.
The dif ferent levels of the user inter face support the test engineer
in specifying a logical structure of the individual test parameters
according to the test specifications. The activation of the climate
chamber as a part of the test benches is also integrated in the user
inter face. The status display (Figure 7) shows the current number
of operating cycles and error messages as well as the violations for
current, speed, or angle limits for each of the five test motors.
The Automobile manufacturers only tolerate rotation angles within
specified tolerances in the endurance test of the output shaft from
a reversing wiper motor. Thus Valeo continuously monitors this angle. The CANoe application is able to distinguish dif ferent levels of
limit violations.
Figure 4:
Configuration of limit values
2/10
Figure 5:
Configuration of pre and post trigger times. In case of
an er ror, all events which occur in this time window are
stored.
09.02.2010
13:13 Uhr
Seite 3/11
RE LI A BLE EN GI NEER ING TEST ING ON A WIP ER MO TOR TEST BENCH
In case of low-level violations the software issues an error message

(Figure 4). If a high-level violation occurs the software interrupts
the test immediately. The dif ferent levels are adjustable in the setup.
from a true motor output shaft movement. The elimination of false

data must occur rather fast due to the real-time signal compar ison
between the physical angel signals and the bus communication.
The application developers of Vector have prepared similar test procedures for the parameters current and temperature. The Valeo test
engineer can pre-select how of ten the limit may be exceed before
the software will terminate the test. In general, each tested wiper
motor can be started individually, i.e. it is possible to interrupt and
continue a test individually. Parameters such as loading torque,
voltage, or current can be adjusted separately.
Error logging stores the data in small blocks, which allows the test
engineers to per form analyses dur ing the test. The test bench software includes status logging which stores the current signals in freely adjustable inter vals.
Dif ferent wiper test benches one solution
Compensation of environmental influences

Some boundary conditions made the development of measurement
and test algorithms very challenging. For example, the test bench
is attached to a climate chamber for temperature testing. The compressor of the chamber transmits vibrations to the test rig and the
tested wiper motor. The high-resolution angle sensor is able to realize the vibrations as movements of the wiper motor even thought
the motor output shaft is not moving. A damping or physical disconnection of the compressor from the test bench would be extremely dif ficult, and an angle sensor with a lower resolution would
not fulfill the required measurement accuracy.
In order to compensate such errors, the measured data are post
processed using digital filter ing and compared with specified speed
limits. In case the software detects a continuously oscillating movement within cer tain limits, it is able to dif ferentiate these signals
After the successful implementation of the CANoe test application

in the durability test bench for reversing wiper motors, both development partners extend the application to test conventional rotary
wiper motors. While other test benches monitor the motor speed
and temperature only, this application improves the data acquisition, real-time data monitor ing and data analysis.
Valeo has already planned an additional expansion: the CANoe test
system should be enhanced to a mobile operating and data acquisition system for bus controlled wiper motors for the use in conventional test benches and even onboard test vehicles. This allows simple analysis of wiper systems in a wind tunnel or road testing.
With the planned extension of the application Valeo benefits from
the large data acquisition and analysis capability of the CANoe software tool. The development team just needs to specify the options
that have to be implemented in the software. The expense is relatively small: Valeo employees supported the Vector team with their
specif ic product know-how and the def inition of the application.
The CANoe application team from Vector started the development
of the test regimen, bus communication and the data acquisition as
well as the evaluation of the test data with two engineers. Subsequent expansions has been realized with one person form both
partners.
Figure 6:
Configuration of test procedures
2/11
09.02.2010
Valeo and Vector clearly exceeded the objectives set for this project
by reacting flexibly to unforeseeable challenges along the development and implementation process. Fur thermore they are planning
an extension of the application as more capabilities of the CANoe
tool become apparent dur ing the application development. Dur ing
the execution of the project the specification had to be redefined in
order to realize additional test features. Usage of elegant software
solutions allows optimizing the application. With the new wiper
motor test bench, Valeo will use the multifunctional CANoe tool as a
continuous system platform from the start of the product development to the validation, thus guarantying its customers the delivery
of reliable products.
13:13 Uhr
Seite 3/12
Dipl.-Ing. (FH) Dietmar Baumgrtner

studied precision mechanics at FH Heilbronn.
He is manager of system and component
testing for wiper systems at Valeo Wischersysteme GmbH in Bietigheim.
Dipl.-Ing. (BA) Benjamin Dietz

studied Mechatronics at BA Stuttgart and
at the Valeo Wischersysteme GmbH company.
After his studies, he changed over to the
testing department of reversible wiper
motors. Currently, he is the electronics
developer for advance development.
Dipl.-Ing. (FH) Marco Rommel

studied electronics with an emphasis in
automation technology at FH Heilbronn.
He works for the Valeo Wischersysteme GmbH
company in the testing department and is
responsible for creating and managing testing equipment.
Dipl.-Ing. Katja Hahmann

studied electrical engineer ing at TU Chemnitz. After her studies, she began working
for Vector Informatik GmbH in Stuttgart in
1997 and is currently team leader of the team
for CANoe Application Development in the
production line Networks and Distributed
Systems.
Dipl.-Ing. (FH) Rainer Brndle

studied telecommunication engineer ing at
FH Esslingen and began working for Vector
Informatik GmbH in 2005. He is project
leader for var ious Valeo wiper test benches as
Senior Software Development Engineer in the
application development team.
Figure 7:
Cur rent status of the five test specimens
2/12
09.02.2010
13:13 Uhr
Seite 3/13
Case Study
Automating ECU Test Execution,
Pass/Fail Detection, and
Report Generation
Nippon Seiki Co., Ltd.
The Customer
The Advantages
From the time it was founded, Nippon Seiki has extended

its business, focusing on the development and manufacturing in-vehicle instrumentation. Nippon Seikis technological competence in this field is highly rated, and as a leading
manufacturer of instrument panels it supplies a large number of automobile and motorcycle manufacturers.
Test Execution Time Dramatically Reduced

Automating ECU test execution, pass/fail detection and report generation helped Nippon Seiki to successfully reduce
total ECU test time from more than 18 hours to just over 12
hours. In particular, test execution time, which previously
took 11 hours, has now been shortened to about 4 minutes!
The more frequently testing is executed, the greater the gains
in testing efficiency. Finally, use of the CANoe Test Feature
Set has dramatically reduced the man-hours needed to perform the tests (see table below).
A System Design Department Manager described the advantages of automatic execution like this: There is certainly
some test case implementation work to be done when automating. But once the test case is created, the ability to reuse
it again and again is a huge advantage. In turn, this improves
overall testing quality.
In this project, 30% of all ECU test cases are automated using
the CANoe Test Feature Set. Nippon Seiki will be expanding its
automated testing coverage in the future and targeting even
greater efficiency in ECU testing.
The Challenge
Reducing ECU testing man-hours while simultaneously improving quality of overall testing
With growing computerization in automobiles, instrument
panels are moving toward multifunctionality. That is why
manual ECU test execution, pass/fail detection, and creating
reports took a huge amount of time. This has resulted in increased ECU testing man-hours, and their reduction has become a major issue.
The Solution
Automation of ECU Testing using the CANoe Test Feature Set
CANoe, provided by Vector, is used by a large number of customers who develop in-vehicle ECUs. The CANoe Test Feature
Set is designed to automate ECU stimulation, pass/failure
detection and test report generation. To solve the issue of
increased man-hours, the following proposal was made to
Nippon Seiki:
Test samples: Delivery of a total of five test samples, including a CAN Message Synchronization Test, Diagnostic Test,
and Gateway Test.
Training of employees involved in testing.
Technical support: In the context of technical support for
customers with maintenance contracts.
The CANoe Test Feature Set can also support fault diagnostics
and serve as a diagnostic tester.
(*) Test No. 2 is executed simultaneously with Test No. 1.
Table: Comparison, in relation to test case and manhours, between conventional test method and the use of the CANoe Test Feature Set
Your contact at Vector:

Katsuhiro Kinoshita
Katsuhiro.Kinoshita@vector.com
www.vector-japan.co.jp
Comprehensive ECU Tests with Fault Simulation

Fault simulation capability is needed in early test phases for efficient functional tests
Besides testing actual functionality, a modern test system for ECUs must also permit testing of the most important fault
cases. This applies to the ECUs communication interfaces as well as to its I/O interfaces. Suitable test systems can be
implemented early in the development process using special test strategies tailored to the needs of the automotive industry. The new compact test hardware VT System from Vector meets the various challenges that face such a test system.
Electronics and software have become indispensable components
in the automobile. Therefore, verification of development results
not only covers the mechanical systems, but to a large extent the
electronic ECUs and their software as well. The complexity of heavily networked systems places high requirements on the test process
and the test tools used. Systematic and comprehensive tests are
necessary in all development phases. Various test methods are
applied in development (Figure 1). Before the classic test runs of
integration tests in the lab or through comprehensive driving trials, the ECUs are first individually tested thoroughly in functional
tests.
In testing ECUs, it is not just the so-called good cases that are
of interest, i.e. processes that represent normal operation. Also
important is broad coverage of potential fault cases. In testing
normal operating functions it is usually sufficient to connect the
ECUs to their original components, operate them and observe their
reactions. Additional devices are necessary to cover fault states;

they are placed in the circuit between the ECUs ports and the original or simulated sensors and actuators (Figure 2). Such test
Figure 1:
Different test methods are used in the various
development phases.
2/14
09.02.2010 13:24:23 Uhr
XXXXXXXX
components are often referred to as fault simulators. They might

be used to disconnect lines to simulate line breaks, for example.
In testing an individual ECU, besides controlling the hardwares
input and output interfaces, the communication interfaces of the
DUT also play an important role. This places high requirements on
the test software, since besides providing pure bus access for
CAN, LIN, FlexRay or MOST it must be possible to comprehensively
and reliably operate the ECUs software or protocol interfaces, e.g.
diagnostics via UDS or calibration via CCP/XCP. So the layout of
hardware and software interfaces has an enormous effect on the
performance, flexibility and, last but not least, the costs of a complete test system.
Challenge of functional testing

In verification of ECU functionality, the primary task is to represent
the ECU in an environment that mimics the real vehicle environment as closely as possible. The sensors connected to the ECU are
operated to activate the functions to be tested, and the ECUs reactions are evaluated. There are very different ways to produce a suitable ECU environment. What is important is that the ECU must not
be able to perceive any differences between the real environment
and the environment simulated by the test system. In the end, the
extent of efforts primarily depends on test objectives.
In the simplest case, an elaborate stimulation circuit is omitted
and the ECUs inputs are operated directly by simple means, e.g. by
manual switches between specific ECU lines. The ECUs outputs
remain unconnected for the most part. Testing the ECUs reaction
might only involve measuring the voltage at an output, for example. Such approaches usually do not lend themselves to automatic
test execution, but they are easy to perform especially during
development.
Increasingly, many of todays ECUs can no longer be operated in
this way. Since they automatically check the sensors and actuators
in many cases, it is essential to connect them during the test. If an
external component is faulty or is not even present, the associated
Simulation of fault situations

To test an ECUs reactions to faults in the connected environment,
the test system must be able to produce various fault situations.
Extensive tests under these atypical conditions are especially
important, because they occur very seldom in driving trials or on
the test bench and are difficult to reproduce. In the development
of hardware and software, many fault situations are frequently
In
Sensor
controlling,
stimulating
system may make fault memory entries, deactivate certain functions in the ECU or generate error messages. So the sensors and
actuators are even needed for tests in which the functionality of a
sensor or actuator is not really of importance.
A commonly used solution is to connect original sensors and
actuators directly to the ECU. Many developer test benches are
equipped with simple connection boxes for this purpose, which
take the necessary components and have suitable cable connections. Similarly, original sensors and actuators are also provided to
the ECUs under test on large test benches. However, automating
the test processes is often problematic, since original components
must be operated, e.g. by actuating robotics.
An alternative to connecting original sensors and actuators is to
use substitute components. For example, a suitable resistor may
serve as a practical substitute for a lamp. Since the ECUs are only
equipped with simple measurement circuits to monitor their connected components, generally a simple sensor or actuator simulation is sufficient. Compared to the use of original components, this
enables compact and simple test systems. Similarly, it is relative
easy to automate user inputs with suitable test setups, e.g. by
using relays or switches.
In so-called Hardware-in-the-Loop systems (HIL) the overall
environment is modeled including physical and dynamic processes in the connected components. In this case, however, simulation
and test execution would require elaborate and cost-intensive test
systems, and they would not always be available where they are
needed. This also applies to the necessary knowledge of operators.
fault
injection
Out
ECU
under Test
CAN, LIN,
FlexRay...
Automated Testsystem
Actuator
fault
injection
observing
reaction
Figure 2:
Fault simulators are inserted
between the sensors/actuators and
the ECU.
2/15
09.02.2010 13:24:24 Uhr
forgotten, because the primary focus of developers is on the

desired functions. To achieve reliability of systems, however, it is
critically important that the ECUs also react properly in response to
faults.
In conjunction with sensor and actuator connections, it is especially important to simulate the following fault situations:
> The electrical wiring is damaged: open circuits, short circuits to
ground or battery voltage, short circuits between certain
connected lines.
> Sensors or actuators are damaged: sensors do not supply any

values, values lie outside allowable value range, or a components electrical properties, e.g. internal resistance or current
draw, do not conform to the specification.
> Incorrect input values, especially incorrect sensor data: from the
perspective of the ECU, the sensor is operating properly and
measured values also lie within the allowable ranges. Yet, the
values are implausible or contradict other sensor values, and the
ECU must recognize this.
In all cases, the ECU must continue to work in a defined way. Furthermore, the faults must be detected correctly, and relevant fault
memory entries must be made. Therefore, besides fault simulation,
it is also necessary to access the ECUs software interfaces typically the diagnostics interface to stimulate input signals and test
output signals.
Integrated solution for ECU testing

Vector supports the analysis, simulation and test automation of
ECUs with the high-performance development and test tool CANoe
[1, 2]. Meanwhile, Vector hardware interfaces offer a reliable bus
interface to CAN, LIN, FlexRay or MOST. Measurement and test
hardware is controlled or driven via GPIB or the serial port, and
integration of standard I/O cards from various manufacturers
enables setup of test benches with a wide variety of complexity.
In driving the ECU I/O lines during an ECU test, Vector offers a
compact solution with the VT System (Figure 3). The ECUs I/O
Figure 3:
The VT System consists of standard 19-inch housings
with their own backplane into which the modules are
inserted. This lets users implement individual and
flexible test solutions depending on requirements.
Actors
VT System
Power Supply
ECU
under
Test
CANoe
CAN, LIN,
FlexRay, ...
Sensors
Vector
Businterface
Figure 4:
The VT System is placed in the I/O
lines between the ECU and actuators or sensors.
2/16
09.02.2010 13:24:24 Uhr
COMPREHENSIVE ECU TESTS WITH FAULT SIMULATION

XXXXXXXX
lines and if necessary original sensors and actuators are connected to the modular system (Figure 4). The PC is connected to
CANoe via a fast Ethernet-based real-time network. This makes it
possible to assemble flexible test systems without great integration or wiring effort. The VT System is well-suited to both small test
setups at a developers desk as well as comprehensive test benches
in the test laboratory.
The VT System simplifies the process of setting up test benches
immensely, since it integrates all components needed for an I/O
channels switching circuit in one module (Figure 5). Examples of
such I/O channels might include an ECUs output for driving a
headlight or an input to be connected to a temperature sensor.
Since two-wire connections are made for all channels, the system
supports all input and output types relevant to practice, e.g. driving motors via an H-bridge in the ECU.
The measurement and stimulation devices contained in the modules are like all components designed for voltage ranges up to
32 Volt that are typically used in the automotive industry. They
require units for signal conditioning, which are already integrated
in the module. The modules can also handle the high currents that
may occur when lamps and motors are driven. Relays on the modules serve to connect the ECU lines to the attached original sensors
and actuators.
It is relatively easy to set incorrect sensor data with original sensors, since here the sensors just need to be operated to be implausible. However, the number of conceivable value combinations is
large. For systematic testing, a high level of automation is therefore desirable; to make it possible to reproduce as many fault patterns as possible within a short period of time. Therefore, one
approach is to replace the original sensors by electronic simulations. They are present on the VT modules for each channel and can
be controlled in any desired way by CANoe as a test system.
The sensors are simulated by a resistor decade or a voltage output with relevant signal conditioning. There are stimulation units
for each of the VT Systems I/O channels, so that all ECU inputs can
be operated simultaneously. This enables simulation of multiple

faults and more complex operating processes.
Additional relays are used to represent faults such as line breaks
and short circuits. In operation, such faults typically occur due to
damaged wiring and problems at the plug connectors. Even when
there are just a few connection lines on an ECU, the enormous number of resulting combinations can hardly be fully tested. However,
with their knowledge of physical conditions existing at the ECU,
persons creating test cases can limit the selection of test cases to
isolated faults and the most likely combinations. For example,
short circuits only occur at adjacent pins on the connector. In the
VT System, the necessary switching options are once again available for every connected ECU pin, so that test case selection is
unlimited, and multiple faults can be covered.
It is somewhat more difficult to simulate sensor and actuator
damage. In this case, it is not possible to revert to the original
components, since the effort required to prepare them is extremely
high. That is why simulated components are used when working on
the test bench. The simulation does not need to be perfect. In
general, it is sufficient if the properties of sensors and actuators
are simulated, and if they are detected and evaluated by the ECU.
In the VT System, an electronic load is available for every ECU output for use in an actuator simulation or load simulation. In simulating faulty sensors, the sensor simulations described above are
implemented as a resistor decade or output voltage. If there are
not enough integrated components for a test, it is possible to connect external load simulations, sensor simulations or measurement
and test instruments via bus bars.
Test case creation accounts for a significant share of overall test
costs. Therefore, for efficient work processes the developer not
only needs the right hardware support, but also an optimal interface to the test automation tool. In CANoe, after a simple configuration of the VT System, all relevant data is available as system
variables. The user selects them via a graphic user interface in the
Test Automation Editor and applies them in the test sequences
Figure 5:
All components
needed to test an
ECUs I/O channel
are contained in
the VT modules.
2/17
09.02.2010 13:24:24 Uhr
(Figure 6). This means that the input and output signals, as well as
most control signals, can be addressed as easily as the bus signals
of the communication interfaces. The VT System is thereby seamlessly integrated in the CANoe test environment.

[1] Riegraf; T., Beeh, S.; Krau, S.: Effizientes Testen in der Automobilelektronik [Efficient Testing in Automotive Electronics]. ATZ (Volume
108), Issue 7-8, 2007, pages 648-655
[2] http://www.vector.com/canoe
Flexible test system for ECUs

Automatic testing of ECUs impose many different demands on the
test system for controlling the ECU interfaces and I/O channels. For
the most part, testing functionality in normal operation just
requires operating the ECUs sensor inputs and evaluating the reactions at the actuator outputs. To represent fault cases, additional
components are needed in the test systems to enable simulation of
implausible sensor data, wiring problems and sensor/actuator
failures.
The VT System from Vector gives the test engineer a compact and
at the same time powerful solution for connecting an ECUs I/O
channels to a test system with CANoe. The modular system provides
for each channel all key components for load and sensor switching as well as their simulation. It also offers the equipment needed
to create the different fault situations. These functions and properties of the VT System make it easy to set up test systems together
with CANoe that can be used flexibly for ECUs in the automotive
field.
Dr. Stefan Krau

studied Computer Science at the University
of Stuttgart from 1990 to 1995. After earning
his degree he worked on the technical staff
of the universitys Institute for Computer
Science in the Software Engineering department until 2001. Since 2002 he has been
employed at Vector Informatik GmbH in
Stuttgart, and is currently Product Manager
for the VT System.
Figure 6:
The VT Systems
measurement and
output signals are
directly accessible
in CANoe on the
right side of the
Test Automation
Editor here.
2/18
09.02.2010 13:24:25 Uhr
2/19
09.02.2010 13:24:25 Uhr
Semi-Synthetic Regression Tests with Real-World Data

Reducing time and hardware effort in software evaluations
It is generally impossible to fully test electronic ECUs with a large number of input values because of the enormous amount
of time required. Despite these constraints, Daimler has achieved a high level of test coverage and good depth in its software testing of electrical power steering units by using the methods of limit value and effects analysis to reduce the number of test cases. Its practical implementation involves simulating driving maneuvers from the real world that are used as a
reference. This article describes how to reduce the set of all theoretically possible test cases and to implement tests with a
development and testing tool.
Now more extensive, time-consuming and therefore more costintensive tests and simulations are necessary, especially when software is used for safety-critical functions in the automobile. Their
goal is to find software errors that may pose a risk to the safety of
passengers and other vehicles in traffic. This applies to steering
systems, especially those assigned to the highest risk class ASIL D
(Automotive Safety Integrity Level). Starting in 2009, legislative
bodies not only in the EU but also to the U.S. and Asia will be
requiring risk assessments and actions in accordance with the IEC
61508 safety standard and its specific modification ISO CD 26262
for the automotive industry. The maturity levels reached must be
documented by appropriate safety verifications.
The advantages of electrical power steering (EPS) compared to
conventional hydraulic power steering systems powered by the
vehicles engine are related to its ability to provide power assist
for the driver according to the situation. The system (Figure 1)

only operates and only consumes energy when the driver turns the
Figure 1:
Testing the Electrical Power Steering (EPS) system for
power assist when needed is extremely complex due to
the large number of input parameters.
2/20
09.02.2010 13:27:20 Uhr
steering wheel. An EPS offers better control and contributes to

improved fuel economy and reduced emissions. For the driver, it is
important for the EPS to exhibit continuity in its capabilities and
driving dynamics. Whenever updates are made to new software
revisions, there is always the risk that undesirable side effects
might be introduced along with the desired changes. In most cases,
they just irritate the driver; in other cases, unlikely input signals
might cause serious malfunctions, including complete failure of the
EPS, that would impair driving safety. Thus whenever the software
is changed, reevaluating it is essential by running regression tests
to reveal changes in steering behavior between different software
levels.
Embedded software requires black box tests

Since EPS is a supplied system, Daimler does not have access to any
detailed information on the embedded software except for a few
parameters and characteristic curves. All tests and evaluations must
therefore be executed as black box tests. Another problem is the
large number of input parameters: There is not enough manpower or
time to run through all theoretically possible combinations in HIL
(Hardware in the Loop) simulations or even real driving maneuvers.
That is because, besides manual steering torque as a basic input
variable, there are 47 other signals that significantly influence the
system. The sheer number of possible combinations of input parameters yields an incredible number of test cases that would take
several years to test. Practical testing would therefore require that

the sum of all possible input combinations be reduced to just a few
representative test cases while achieving high test coverage.
This can be achieved by combining and applying several test
methods, such as the equivalency class method, limit analysis and
the pairwise method. Daimler uses the HIL test bench in effects
analysis to find those signals that have the greatest impact on system behavior. In addition to the three test methods mentioned,
optimization by knowledge integration, i.e. focusing on frequently
occurring input combinations in the application, is indispensable.
Knowledge integration (Figure 2) produces meaningful test cases
and makes a valuable contribution toward increasing software
quality. After the reduction process, 704 relevant test cases
remained, requiring approx. 12 hours of testing.
Real-world data instead of high-cost HIL

In practical tests on the HIL test bench, semi-simulated driving
maneuvers (replaying and calibrating recorded real driving maneuvers) play a key role. The tests are based on a catalog of standard
driving maneuvers that define the desired EPS behavior in specific
situations. These include actions such as slalom driving, ISO lane
change, circular driving, braking in a curve, steering wheel pull,
Elk test, etc. Vehicle developers drive these standard maneuvers in
real vehicle tests. This involves logging the bus traffic in the vehicle by laptop with CANoe, the test and simulation tool from Vector
Figure 2:
Reducing the
number of test
cases by knowledge integration
2/21
09.02.2010 13:27:21 Uhr
(Figure 3). This real world data can then be replayed 1:1 on a
test bench to recreate the EPS as a virtual environment.
However, it does not make sense to just test the original driving
maneuver; instead the EPS is tested in modified scenarios of the
tests cited above as well as in limit conditions, e.g. at higher vehicle speeds, different engine speeds, friction values or modified
manual steering torques. To do this, it is necessary to set and
adjust certain parameters during the simulations. In the test
system developed by Daimler, the logged measurement data are

sent to a Replay block in CANoe for playback (Figure 4). In the first
branch, a blocking filter removes the CAN messages sent by the EPS
in the vehicle to avoid overlapping signals. In the second branch,
the system generates the calibrated signals and computes the analog voltages. This is done with the help of the script language CAPL
integrated in CANoe, which is based on a simplified C-language
syntax. This makes it easy to calibrate real measured signal values
for the test cases, simulate different manual input torques, and
generate various target engine speeds and controller releases.
Digital and analog interfaces
Figure 3:
Test setup for logging real bus communication, driving
the HIL and evaluating measured values.
The interface hardware between the laptop and HIL system is the
PCMCIA card CANcardXL, whose interface physics can be optimally
configured to application requirements via two interchangeable
connection cables. A so-called CANcab is used, first, to have the
system send the (calibrated) remaining-bus simulation, and, second, it receives the CAN communication generated by the EPS in the
HIL environment. CANoe logs and saves all communication for later
evaluation. An IOcab is responsible for outputting the analog signal
voltages for simulated manual steering torque, target engine speed
and engine brake enable. The engine brake in the HIL simulates the
effective resisting moment due to friction and rolling resistance.
The HIL measurement data (Figure 5) can be conveniently analyzed offline with Matlab/Simulink. To do this, CANoe exports the
target and actual values in .mat format. So far, no online evaluation has been necessary, but it would be possible by integrating the
Matlab/Simulink models directly in CANoe. The EPS is considered
functionally capable if deviations of the actual EPS torques from
the corresponding target EPS torques do not exceed a defined limit
(Figure 6). Only then does it make sense to conduct further tests
Figure 4:
Various internal
processing blocks
are used to log
and replay the
data in CANoe.
2/22
09.02.2010 13:27:22 Uhr
SEMI-SYNTHETIC REGRESSION TESTS WITH REAL-WORLD DATA
in the real vehicle, since unanticipated risks for driver and vehicle
have now been reduced to a minimum.
and those that are smaller, with each performing a test in that
range. The equivalence class method is prescribed by IEC
61508/ISO 26262.
Summary
Limit Analysis
The testing approach for evaluating software levels and revisions
described here met Daimlers expectations for the project. Suitable
test methods combined with intelligent knowledge integration reduce
the theoretically possible number of test cases to just a few conceivable combinations of input signals. Daimler engineers were able to
obtain conclusive test results on the behavior of the EPS as a black
box with relatively little time and effort. Instead of computing driving
situations and effects analysis with a complex, exact vehicle model in
cost-intensive HIL systems, logged real-world data is used, which can
be modified in semi-simulated driving maneuvers. The simulation and
test system CANoe provides valuable services here; it runs on a laptop, so it is ideal for logging standard driving maneuvers in the real
vehicle and conducting tests. During these semi-simulated driving
maneuvers, the Vector system is responsible for key system functions
ranging from replaying, filtering and modifying the real world data in
real time to controlling the test flow with the CAPL script language.
Not only do its lower costs argue for using CANoe so does the positive experience the department has had with the system. The test
platform, together with the HIL computer, is so compact that Daimler
can take the entire system on real test drives at any time.
Figure 5:
Real measured target values are compared to HIL
output values in Matlab.
Equivalence Class Method

Equivalence classes are made up of input or output values presumed to elicit an identical system reaction, i.e. instead of
testing all of them, only one or just a few representatives of
the equivalence class are tested. All valid values of a defined
input range might define one equivalence class, for example,
when values outside of the defined value range represent
another equivalence class. The latter class can itself be subdivided into values that are larger than the valid value range
This is based on the equivalence classes, where the primary

focus is on the limits or extremes of the value ranges, e.g.
maximum defined signal values, steering torques, etc. Experience has shown that the causes of errors can often be found
there. Besides limits, it also makes sense to test values 1
greater and 1 smaller to discover overruns, interpolation
errors, etc.
Pairwise Method
This is the accepted and widely used practice for testing all
combinations of two signals. However, since blind application
of this method almost always leads to unlikely test combinations, it makes sense to select combinations with knowledge
integration, to focus on typical input combinations of the
application in question.
Andreas Herp (Graduate Engineer),

studied electrical engineering at the University of Karlsruhe. Since October 1998 he has
been employed at Daimler AG, first as a
development engineer, and since 2006 as E/E
project leader for ECU and software development of electrical power steering, and he
directed the thesis work by Mr. Herbert.
Michael Herbert (Graduate Engineer),

studied electrical engineering and information technology at the Technical University of
Darmstadt. As part of his undergraduate
thesis work at Daimler AG, he researched
the topic of Effects and Limit Value Analysis
of an EPS. Since October 2008, he has been
working at Daimler AG as a computational
engineer for handling simulations on the
S-Class.
Oliver Falkner (Graduate Engineer),
studied electrical engineering at the University of Stuttgart. After graduating, he joined
Vector Informatik GmbH in Stuttgart in 1999,
where he is currently senior product management engineer in product management of
the Networks and Distributed Systems product line.
2/23
09.02.2010 13:27:23 Uhr
Model-Based Testing for Better Quality

Advantages of test case generators in model-based development processes
Test case generators that implement the concepts of model-based testing in functional model development have been commercially available since 2007. The automatically generated test cases simplify regression tests during iterative development of complex models. Transformations make it possible to re-use the test cases that are generated, e.g. in ECU acceptance testing, so that test cases do not need to be recreated manually. This results in considerable savings in time and cost
for functional developers.
Software engineering is a discipline of computer science that has
great innovative potential. Great software complexity and the overabundance of resulting information raise the quality assurance
issue of how to effectively guarantee consistency of the model and
code. Test strategies and processes used during the early stages of
development will reveal technical and design errors early, when
they can be corrected much more cost-effectively.
Model-based development is a software engineering method
which in addition to documenting the system also utilizes automatic generation to produce a large share of the test documentation. In practice, most test cases are still created manually. In a
classic document-based approach, test cases are derived from
requirements and described in a test specification. From this specification, tests are implemented to verify proper software implementation in the ECU (Figure 1).
Over the past five years, automotive OEMs have been applying
more and more model-based methods to develop embedded software. One possible approach that integrates these model-based
methods into the development process is one in which the software
is manually implemented in the ECU while functional models are
created in parallel (Figure 1). The development of executable functional models represents a quality improvement in requirements
analysis and development. First, the functional models define functions and then validate them with respect to the given
requirements. The test specification should be used again to verify

the functional model. This process reveals errors and inconsistencies in early development phases, which can then be corrected at a
fraction of the cost of correcting them later, after system or acceptance testing. Broad tool support also promises minimal time to
develop the ECU software, e.g. by using automatically generated
production code (Figure 1).
Stepwise development and verification of complex functional
models assumes efficient test methods. A check must be made at
each step in the development process to verify that no errors have
been introduced. In a process known as model-based testing, test
case generators take functional models and automatically generate
test cases, which can then be automatically executed, evaluated
and documented.
Other issues involve where it makes sense to apply automatically
generated test cases and which advantages they offer in the development of embedded vehicle systems. The new approach can be
used during iterative development of functional models to automatically generate test cases for regression tests, for example.
Another possibility is to re-use the test cases generated from this
development phase in later testing phases of the development process, such as in ECU acceptance tests (Figure 1).
Figure 1:
Comparison of
different
approaches to
developing ECU
software
2/24
09.02.2010 13:27:06 Uhr
Test case generators simplify regression tests

Requirement definitions are often subject to change. Any errors
discovered in the requirement definitions are corrected, and new
functions may be added to extend the functionality of the system
being developed. Later in the development process, the implementation is often restructured or simplified all while retaining its
functionality, of course. Functional models that have already been
developed are then adapted to the new conditions. During this process, the developer must ensure that changing a functional model
does not introduce any new errors or undesirable effects on functionality. This can be accomplished by using regression tests [1].
Three steps are necessary to attain this goal:
> A suitable Model-in-the-Loop (MiL) test environment must be
developed for the regression tests
> Test cases must then be automatically executed in this MiL test
environment
> Regression tests will be automatically evaluated
A key aspect of regression testing is the quality of the comparison
of a modified functional model with its previous version. One measure of this quality is code coverage, which is why comparing different versions of a functional model requires the greatest possible
coverage. In test cases related to requirements, greater code
coverage entails immense effort, because if there are coverage

gaps, the related code sections must be analyzed, and other
requirement-based test cases may need to be manually created
until the necessary code coverage is attained. Because of this
immense effort, it is no longer advisable to manually create test
cases for the regression test.
One answer lies in the use of new commercially available test
case generators, such as Simulink Design Verifier from The Mathworks or Telelogic Rhapsody ATG from IBM. Test cases are automatically generated after specifying a specific code coverage to be
attained. The test cases then increase the quality of the comparison. In addition, the tools can often simultaneously generate an
MiL test environment, execute test cases and automatically generate a test report. This results in a working method that can be used
throughout the system which has quite short throughput times.
This in turn further simplifies the execution of regression tests for
functional models, which results in cost and time savings.
Figure 2 shows an implementation of a regression test in a Model-in-the-Loop test environment. Functions are modeled in Simulink/Stateflow, while the Simulink Design Verifier generates the
test cases. In principle, other modeling tools could also be used,
provided that they can be obtained with test case generators.
The Test Cases block shown in the diagram (Figure 2) contains
the automatically generated test cases and stimulates the Test
Figure 2:
Setup of a Modelin-the-Loop test
environment for
regression tests
in MATLAB/Simulink. A script
generates test
reports and automatically adapts
their output
format
2/25
09.02.2010 13:27:06 Uhr
Unit system under test. This represents the modified functional

model. The Expected Results block contains the reference outputs
from the previous version of this functional model. In the Regression Test Analyzer block, the newly generated outputs of the modified functional model are compared to the reference outputs at
each step of the simulation. After the test run, a script automatically creates the test report and adapts it to the desired output format. In this case, the output format matches a CANoe test report by
Vector. If the evaluation finds a difference in the outputs, checking
must indicate whether the difference is acceptable or whether it is
an error.
The iterative approach presented here is an efficient way to support continuous improvement and adapt the functional model to
new requirements. It also improves the quality of the functional
model. In addition, verification at each step in the development
process ensures that no new errors have been introduced, further
improving quality. Developing functions with this model-based
approach will make test cases available. The goal is to not only use
these test cases for regression testing of functional models, but
also for later test phases in the automotive software engineering
process, such as in ECU acceptance testing.
Re-using test cases in ECU acceptance tests

The goal of the acceptance test is to verify that software functions
that suppliers implement in ECUs behave as defined in the specification. To perform an acceptance test, suitable test cases must be
created which test the specified functionality. Clearly, one potential way to reuse the test cases generated from model-based development is in a Hardware-in-the-Loop test environment. The
advantage here is that the test cases do not need to be manually

re-created.
A tester wanting to re-use the test cases may find that changing
the test environment from Model-in-the-Loop (MiL) to Hardwarein-the-Loop (HiL) also shifts test boundaries. Test cases in the MiL
test environment refer back to the logical input and output signals
of the functional model. Test cases in a HiL test environment, on
the other hand, require physical signals, e.g. CAN signals, to stimulate the system and evaluate system behavior. It is therefore necessary to transform the test cases, which involves mapping logical
signals to associated CAN signals (Figure 3).
Also, when performing a transformation it must be remembered
that test cases in the modeling tool do not necessarily have the
same data structure or data format as test cases in a tool for HiL
tests, e.g. in CANoe.
In practice, XSLT Stylesheets might be used to perform such a
transformation, for example; this assumes that test cases can be
exported from the modeling tool in XML format. Before the test
cases may be transformed to suitable executable test scripts for the
given HiL test environment, an intermediate step is necessary:
mapping the signals, e.g., using an Excel table. Visual Basic for
Applications replaces the relevant items in the XSLT Stylesheet
where the mapping is implemented. Finally, the transformed test
cases are linked and automatically executed in CANoe. An automatically generated test report helps in evaluating the test results. All
necessary steps in this tool chain can be automated, which yields
time and cost savings.
Acceptance testing with reusable test cases now tests both the
software integration and the hardware-software integration. Testing verifies that the software components properly interact with
Figure 3:
Procedure for re-using test cases in
a Hardware-in-the-Loop test
environment. A precondition is
transformation of the test cases.
2/26
09.02.2010 13:27:07 Uhr
MODEL-BASED TESTING FOR BETTER QUALIT Y
one another via their specified interfaces [1]. Also, the interplay of
the complete software system with the ECU hardware is tested in
the HiL test environment. This verifies the entire implementation
in the ECU.
Summary and Outlook

Powerful new test case generators are now commercially available
which make it possible to conduct efficient regression tests during
model-based development of vehicle functions without any additional effort. Test cases generated can be re-used in later test
phases of the automotive software engineering process, such as in
ECU acceptance testing. This requires converting the test cases by
means of a suitable transformation to produce test scripts for the
specific HiL test environment.
A method-based approach to testing may be applied to modelbased function development with functional descriptions in
MATLAB/Simulink. Use of model-based test methods is being studied in ongoing research projects. For example, the goal of the
VitaS3 research project at the University of Applied Sciences in
Regensburg is to determine the extent to which formal and semiformal description languages such as the Object Constraint Language (OCL) and temporal logic methods can be used to generate
test cases via model transformations [2]. The use of formal description techniques is prescribed in the primary industrial standard for
functional safety IEC-61508 for safety-critical systems. This
approach enables virtual integration of vehicle functions.
Wolfgang Hartig (M. Eng.),

obtained his Master of Engineering degree in
Electrical and Microsystems at the University
of Applied Sciences in Regensburg. He conducted his Masters thesis work at Vector on
the topic: Study of the potential uses of
automatically generated test cases starting
from software models. Today, he is
employed in the area of Technical Consulting
and Engineering Services at Vector. E-mail:
wolfgang.hartig@vector-informatik.de
Albert Habermann (Graduate Physicist),
served as an advisor for the Masters thesis of
Mr. Hartig as part of his work in Technical
Consulting and Engineering Services at
Vector (with a focus on model-based SW
development and testing). Today, Mr. Habermann is project manager for the eASEE
process tool in the Customer Service area
at Vector.
E-mail:
albert.habermann@vector-informatik.de
Jrgen Mottok, (Prof. DSc.),
teaches computer science at the University of
Applied Sciences in Regensburg. His areas of
teaching include: Software engineering, programming languages, operating systems and
functional safety. He directs the Laboratory
for Safe and Secure Systems (LaS3), is a member of the advisory board of the Bavarian
Cluster of IT Security and Safety, and active
in other working committees. E-mail:
juergen.mottok@e-technik.fh-regensburg.de
[1] Liggesmeyer, P.: Software-Qualitt, 2002
[2] Laboratory for Safe and Secure Systems LaS3, VitaS3 research project,
(www.las3.de/englisch/forschung/forschungsprojekte.html)
2/27
09.02.2010 13:27:07 Uhr
Efficient Airbag ECU Tests

Automated tests during development shorten project times, increase testing depth and
make it possible to reproduce errors
In the automobile, airbags are among the safety-critical systems whose reliability can be a matter of life or death. The airbag control unit is responsible for proper operation of the entire occupant restraint system, consisting of all sorts of airbags, belt tensioners, sensors and switches. Even during product development, numerous validation tests are indispensable at all development stages. A new test system at the Robert Bosch company increases efficiency in early test phases in
development; it shortens test times while simultaneously increasing testing depth. It also reduces the number of test
iterations for system tests on existing HIL test benches.
The functional integrity of the safety system depends on the airbag
control unit. Airbag systems must operate absolutely error-free,
and so they are subject to the most stringent safety requirement
level: ASIL Level D. It requires continual monitoring of all of the
system components involved such as squibs, sensors, switches and
the airbag control unit itself. Fault conditions are stored in fault
memory and can be read out in the service garage.
The test system presented here focuses less on crash-triggering
tests, and more on validation of software requirements derived
from customer and internal requirements. In addition, the test
hardware is used to simulate the vehicle environment of the target
systems. The hardware makes it possible to automatically simulate
nearly all external system states that are relevant to functional
software tests (Figure 2). One of the test systems capabilities is to
generate various error states of the airbag system to study the

ECUs behavior in such situations. The desire to improve test quality
and automate test sequences in testing that supports development
motivated Bosch to subcontract the development of a compact,
mobile airbag test system. The goal was to obtain a flexible system
that implements the requirements of early test phases more costeffectively than powerful HIL systems (Figure 1), and which is
well-suited to worldwide use at all Bosch development sites for airbag systems.
2/28
09.02.2010 13:24:36 Uhr
Requirements of the new test system

In the framework of project services, Vector Informatik developed
the test system software and integrated the test hardware. The
project-specific hardware was designed and built by TBM SoftwareEntwicklung & Elektronik (TBM). In the joint planning phase, it was
determined that software and hardware requirements for the new
system would vary widely, because it would have to handle many
Bosch projects for different OEMs, vehicle lines and variants. The
goal here was to find a reasonable compromise that would allow a
majority of the software requirements to be validated for the ECUs.
A key requirement is simulation and monitoring of the ECUs
immediate environment. This environment consists of squibs,
switches, peripheral acceleration sensors, warning lamps and the
CAN bus. To simulate line errors, the system must be capable of
generating short circuits between lines and to different voltages,

for example. Resistor decades simulate the operating ranges of
squibs and seatbelt switches in this application. The test system
must also simulate connection of the wrong lines as well as overvoltages and undervoltages. This involves use of an integrated voltage supply to run through various individually programmable voltage curves. Afterwards, a check is made to determine whether the
airbag ECUs internal monitoring correctly identifies the error
states.
Another important requirement is configurability of the test system. The number, names and assignments of the pins used, as well
as the number and type of squibs and seat belt buckles vary with
each project. These aspects must be taken into consideration, so
that the test system can be conveniently used in different projects.
Automatable tests, easy operation and flexible test

software
Figure 1:
Use of the new test system in the V-Model
Vectors CANoe test and simulation software and integrated Test

Feature Set (TFS) made a significant contribution toward quick and
successful implementation of the new test system. Basic properties
of TFS are automatic execution of ECU tests and parallel generation
of test reports. The test sequences themselves are created in CAPL,
a C-based script language. To conveniently support specific application cases, project-specific extensions are made.
The test hardware from TBM, specially developed for this project,
is controlled via CAN. The interface to CANoe is made via a channel
of the Vector CAN hardware. To drive the TBM test hardware, Vector
developed a C++ DLL, which provides all of the necessary CAPL test
functions. This makes additional functions available to users,
including automatic reporting (Figure 2).
Figure 2:
Layout of the test
system
2/29
09.02.2010 13:24:37 Uhr
In creating the test sequences, it is often very advantageous to

be able to address ECU pins by meaningful names. Mapping tables
handle the assignments between test hardware channels and project-specific pin names.
CANoe, the central control unit, is responsible for core functions:
Test hardware drive control via CAN, CAN remaining bus simulation,
diagnostics and reporting (Figure 3). Extensive CAPL functions
allow Bosch to create complex test cases as well. These functions
are used to control switching of short circuits, setting of resistances
and setting of current sources. They are also used to send and
evaluate CAN messages, e.g. in testing the ECUs error memory.
Additional CAPL convenience functions are used to search for a specific ECU pin name, or to query switch states and compare them.
There are also arithmetic functions for processing arrays. CANdela
files in CDD format or ODX files may be used as standard diagnostic
description files. Since diagnostic descriptions are not available in
these formats on all projects, Excel tables are also used. This makes
it possible to use symbolic descriptors for diagnostic services and
parameters in all projects. The Bosch airbag ECUs also support production diagnostics an internal company diagnostic protocol.
Production diagnostic services are already integrated in ECU implementations very early in development. These services have been
integrated in CANoe. XML/HTML reports generated from the CANoe
TFS can be modified to be project-specific, and test log depth of
detail is set separately for each test run.
At the Bosch company, the test system was systematically further developed and a test control was implemented for individual,
manually executed tests, for example. The system offers a graphic
CANoe operating panel for this purpose, and this renders the previous manually operated test hardware unnecessary.
The results
The new test system subcontracted by Bosch and implemented by
Vector and TBM includes project-dependent squibs, seatbelt buckles and configurable warning lamps. It is universally applicable for
the airbag ECUs of most OEMs, vehicle lines and equipment variants, and it is well suited for automated software requirement tests
as well as error replication and analysis. In addition, it is already
being used for certain software integration tests and module tests.
The system lets users automatically test ECU functions, log the
observed behavior and recognize deviations from expected behavior. In total, 42 systems are now in use in Germany, India, the USA
and Japan. The cost advantage compared to large HIL test benches
enables its use in low-cost countries.
The primary software and hardware developments were completed within the very short time of just half a year. For the time from
startup to in-house maintenance of the new system by Bosch,
Vector was the central contact partner for application support and
modifications to the overall test system.
Figure 3:
Components of the CANoe
configuration
2/30
09.02.2010 13:24:38 Uhr
VALIDATING SOFTWARE REQUIREMENTS BY EFFICIENT AIRBAG ECU TESTS
Summary and outlook

The new airbag test system for software requirements testing
exceeded expectations in fulfilling project goals. After an initial
automation effort, the system enables significantly shorter test
times despite the much higher number of test cases. In addition,
early implementation of automated tests during software development means that errors in the airbag ECUs can be detected and corrected more quickly. Subsequent validation stages build upon a
high level of software quality. Global use of a uniform test system
for software validation levels at all Bosch sites for developing airbag ECUs makes it easy to reproduce faulty behavior independent
of the site. Excited about the many capabilities and potential of
CANoe, Bosch is already considering further extensions of its airbag test system.
An airbag triggering process consists of a sequence of highly
precise, interrelated and coordinated individual actions. Sensors supply information on the vehicles speed, transverse and
longitudinal acceleration values and rotational movements.
The airbag ECU applies other parameters in its computations
such as weight distribution on seats, states of seatbelts, belt
tensioners and switches to determine which airbags should
be ignited, at what times and with which strength. The air bags
are only activated for a short period of time, so precise ignition time is a crucial parameter. Another important parameter
is the speed at which the bags fill, which can be influenced by
the use of different ignition pills. The ignition pills are pyrotechnical propellant charges that generate a lot of gas in a
short period of time.
David Oberschmidt (Dipl.-Ing.)

studied Physics at the KTH Stockholm. Since
2002 he has been employed at Robert Bosch
GmbH (in the Airbags area until 2006, and
since then as technical project leader for ESP
application projects in France).
E-mail: david.oberschmidt@fr.bosch.com
Frank Bhm (Dipl.-Ing. (FH))

studied Automotive Engineering at the University of Applied Sciences at Esslingen. He
has been employed at Robert Bosch GmbH
since 2002, where he works as a development
engineer in the Airbag area, specializing in
the areas of Test Automation and Test
Tooling.
Tel. +49-711/811-20939
E-mail: frank.boehm@de.bosch.com
Dr. (rer. nat.) Martin C. Geisler
studied Physics at the Ruhr University at
Bochum, Germany, and at the University of
Sussex, England. He has worked at the Riken
Research Institute in Saitama, Japan, and he
earned his doctorate degree at the MaxPlanck-Institute for Solid State Research in
Stuttgart. Since 2005, he has been employed
at Robert Bosch GmbH as sub-project leader
and later as team leader for software validation in the Airbag area.
Tel. +49-711/811-24324
E-mail: martin.geisler2@de.bosch.com
Katja Hahmann (Dipl.-Ing.)
studied Electrical Engineering at the Technical University of Chemnitz. Since 1997 she
has been employed at Vector Informatik
GmbH in Stuttgart where she is group manager for CANoe application development in
the Networks and Distributed Systems
product line.
Tel. +49-711/80670-459
E-mail: katja.hahmann@vector.com
2/31
09.02.2010 13:24:38 Uhr
09.02.2010
13:05 Uhr
Seite 1
Vehicle Diagnostics The whole Story

Ef ficiency gains by standardization and
the use of tool-supported processes in
diagnostic development
The development and introduction of new diagnostic concepts and diagnostic solutions of fer signif icant potential
to automotive OEMs and suppliers for realizing ef ficiency
gains and quality improvement. Growing complexity in
automotive electronics can only be mastered technically
and economically by use of nonproprietary standards
such as ODX, close cooperation and power ful tools. This
ar ticle of fers an over view of topics relevant to the past,
present and future of automotive diagnostics as presented and discussed in October 2006 before an audience of
350 par ticipants at the Vector Congress in Stuttgart.
20 years of automotive networking and diagnostics
The fast growth of electronic functions in vehicles dur ing the second half of the 1980s at first led to many insular solutions that prevented comprehensive concepts from taking hold in the area of
electrical/electronic architectures. At the beginning of the 1990s a
consolidation phase began that was marked by development of
electrical/electronic structures and associated networking topology from a comprehensive perspective. This meant that electrical/electronic content and its networking could claim an undisputed position in the vehicle. The recognition that many functions
could only be implemented sensibly with the help of electronics also prevailed. So the image of electronics transformed from being a
necessary evil to being a key to new, interesting and innovative
functions. The three bus nodes in commercial vehicles in 1989 have
become more than 70 today in similarly equipped vehicles; see Figure 1. The underlying software amounts to about 10 million lines of
programming code.
This trend has not been without consequences for diagnostics either. Twenty years ago the diagnostic capability of a function was
not even considered until shortly before production star tup. Today
basic diagnostic functions usually exist as early as in the B-Sample.
Handling of diagnostics has improved signif icantly. In the times of
flash codes the process required that users tediously count the
number of flashes and convert them to error codes based on printed-out tables. Today testers output instructions in clear text.
In the past it was possible to do without tool support entirely. Today power ful diagnostic tools are an everyday reality. It is possible
to create the diagnostic specification, generate ECU-specif ic code
and parameter ize the diagnostic tester utilizing the single source
principle. A precondition is that specification of diagnostics must
be shifted to the beginning of the development process (Frontloading); see Figure 2. The ODX format also enables cross-OEM exchange
of diagnostic data.
Figure 1:
Development of electronic networking based on the example of
the E-Class model series W210
(1995) and W211 (2002).
3/0
From proprietary diagnostic tool to standard tool chain

The developing trend of diagnostic tools is similar to the trend of
electronics in the vehicle. Back in 1990 automotive OEMs created
their own tools in-house. Specialists in dif ferent departments customized their tools precisely to their requirements and specif ic applications. This produced individual in-house solutions within each
OEM and even for dif ferent process steps.
About 1995 automotive OEMs came around to a new way of thinking, i.e. that they wanted to once again focus more on their core
business. Accordingly, tool development was outsourced to external service providers. Initially, these outsourcers produced special
in-house solutions as well, but they succeeded in reducing the dif ferences between tools and standardizing existing solutions within
cer tain limits. This trend continued until open, nonproprietary diagnostic tools became available on the market in the year 2000. For
users, the route of product licenses is noticeably more cost-ef fective than assuming responsibility for developing and maintaining
proprietary tools in-house. Moreover, there are shared benefits due
to synergistic ef fects of the combined experience of other market
par ticipants. In 2005 the tools began to support general standards.
Contemporary tools of fer standardized inter faces that can be
seamlessly integrated into existing tool chains.
Old and new standards for diagnostics

Standards currently in the spotlight include the diagnostic data
model per ISO 22901-1 ODX (Open Diagnostic Data Exchange, ASAM
MCD-2D), the hardware inter face per ISO 22900-2 (D-PDU API) and
09.02.2010
13:05 Uhr
Seite 2
the inter face between the runtime system and the test application
per ISO 22900-3 (ASAM MCD-3D, D-Server API). Each of the programming inter faces mentioned are available to the user as software librar ies. Also wor thy of mention are the diagnostic-relevant
standards per SAE J2534 and in the context of AUTOSAR standardization AUTOSAR WP4.2.2.1.4 (DCM, DEM). Fur thermore, the UDS diagnostic protocol per ISO 14229-1 (Unified Diagnostic Services on
CAN) will gradually replace older protocols such as the K-Line per
ISO 9141-2 and KWP2000 as well as KWP2000 on CAN; see Figure 3.
Character istics of modern diagnostic solutions

The development of comprehensive, homogeneous diagnostic solutions is a challenge. It requires studies and ef forts on many dif ferent levels, in order to satisfy all requirements under one roof. On
the one hand, this involves rationally creating power ful diagnostic
systems and on the other hand developing a user-friendly approach. It is only possible to realize these two goals with a universal, complete and practical diagnostic tool chain. Solutions must be
specified, implemented and documented for both the overall vehicle diagnostic system and diagnostics for specif ic ECUs. Fur thermore, consistent management and distribution of diagnostic data
must be assured. That is because the applications of diagnostic solutions range from the development process with its many dif ferent
areas of focus, to quality assurance in production and finally diagnostics in the service garage.
Figure 2:
Diagnostic tool chain based on
single-source principle utilizing
standardized exchange for mats.
3/1
09.02.2010
13:05 Uhr
Seite 3
The above-named standards serve as a foundation and building

blocks for implementation of such comprehensive diagnostic systems. They benefit individual market par ticipants without restraining natural competition. Besides achieving cost reduction, standardization brings the user additional advantages such as interchangeability of products, components and data. It can be expected that even more standards will be created in the future, which in
turn will af fect the tools used.
the standardization committee. For suppliers, for example, it is crucial that they be capable of handling projects for dif ferent automotive OEMs with one and the same diagnostic tool. And to accomplish
a gentle migration from the existing solution to the standardized
diagnostic system, special temporary measures are of ten necessary
dur ing a transition time. In the introductory phase for new standards it is impor tant to support multiple parallel versions in a consistent way.
Practical capabilities are trump
Openness for progress and innovation
In introducing modern diagnostic tools, focus on the needs of users

is of fundamental impor tance for their acceptance. The user should
not be confronted with the full complexity of the standards. Rather
it makes sense to present a diagnostically-driven perspective of the
data to the user. Special knowledge of the underlying data format
should not be necessary. It is also impor tant to optimize typical recurring work steps by guiding the user in per forming the necessary
tasks correctly, consistently and with time savings. In par ticular
this includes avoiding redundant processes and wherever possible
reusing already existing data material.
Even if standardization and innovation seem to be two irreconcilable goals at first glance, automotive electronics is character ized by
continual development. Progress is one of the most impor tant key
per formance indicators for automotive OEMs and suppliers. Therefore expandability of currently used tool chains is always in demand, so that innovations and functionalities of future standards
can be utilized or tested in advance.
Flexibility in handling customer-specif ic features

In all of the ef forts to achieve uniformity and standardization in
creating power ful tools, it is impor tant not to lose sight of flexibility. Current diagnostic standards of fer a cer tain degree of latitude
that can be exploited to address supplemental requirements not
covered by the standard. These include customer-specif ic features
and conventions or special wishes not supported by the major ity of
Enough ideas and tasks still remain to ensure that in the future automotive electronics, networking and diagnostics will continue to
improve on the achievements of the last 20 years and adapt them to
new requirements. It must be assumed that the pace of innovation
will accelerate even more, and even closer collaboration will be
necessary between automotive OEMs, suppliers and tool producers.
This also per tains to a common approach in dealings with legislative bodies.
Figure 3:
The most impor tant applied networking and diagnostic technologies over the past 15 years.
3/2
09.02.2010
13:05 Uhr
Seite 4
VE HI CLE DI AG NOS TICS THE WHOLE STO RY
Universal and automatic tool chain

Similarly, there is much future potential for diagnostics, now that it
has succeeded in quasi evolving from a minor appendage to functions to a function in its own right. This signifies the step from
simultaneous development to integrated development, which results in even closer cooperation between diagnostic and functional
developers. For the diagnostic system a model-based approach also
came to fruition, which applies knowledge acquired from FMEA
(Failure Mode and Ef fects Analysis) for example. Tools like DaVinci
and CANdelaStudio from the Vector Informatik company, IQ-FMEA
and Matlab/Simulink enable diagnostic design strategies utilizing a
universal and automated tool chain, from modeling tool to author ing system.
Diagnostic developments at DaimlerChrysler

DaimlerChrysler AG and Vector Informatik GmbH have expanded
their close cooperation over the past several years, including in the
area of diagnostic tools. Easy and convenient use of tools and description of all diagnostically-relevant data in a uniform format are
impor tant principles of their joint projects. Data and diagnostic
functions are only formally specified once in the solutions, which
are based on the single-source principle. Therefore they are universally available to all project par ticipants and suppliers in machine-readable XML description files; see Figure 2.
In CANdela (CAN diagnostic environment for lean applications)
Vector Informatik structured its diagnostic product line-up with
suf ficient flexibility so that OEM-specif ic export formats could be
integrated. DIOGENES, the DaimlerChrysler-specif ic description data format, is also automatically generated and is then processed by
the uniform diagnostic runtime system. The requirements and experiences of other cooperation partners such as OPEL/GM and agricultural machine producer CLAAS have had signif icant influences
on the CANdela approach too. In the meantime Vector has also been
working together with companies such as Fiat, Ford and numerous
automotive suppliers worldwide.
Handling special project-specif ic features with templates

In formal diagnostic description templates, or just templates, are
impor tant services for taking into consideration specif ic requirements of the manufacturer, project and vehicle model. Fully specifying diagnostics at a very early time prevents most misunderstandings, errors and iterative optimization loops in the diagnostic development process. The use of CANdela is firmly established in the
development process at DaimlerChrysler. ECU suppliers not only develop the diagnostic functions in the ECU; they also supply the associated formal descriptions. Of ten standard software components
are used to implement diagnostics in the ECU. The diagnostic component CANdesc (CAN diagnostic embedded software component)
can be automatically generated from the CANdela data; see Figure
2. This gives ECU and vehicle producers a way to achieve uniform
implementation of the diagnostic protocol across all products.
ODX exchange format and UDS diagnostic protocol

The international standard ODX (Open Diagnostic Data Exchange)
serves as the standard for exchanging data and nearly all diagnos-
Figure 4:
Complex bus networking in the LEXION
combine har vester.
3/3
09.02.2010
tic information between individual tools, as well as between automotive OEMs and suppliers. It is being developed within the ASAM
standardization body (Association for Standardization of Automation and Measur ing Systems) and is expected to be released as ISO
standard 22901-1 in 2007. DaimlerChrysler plans to replace its own
DIOGENES format by ODX on future projects.
The CANdela approach handles import and export of ODX data and
enables a smooth transition from proprietary formats to the standardized exchange format for suppliers. Moreover, the Vector Tools
CANoe, CANape, CANdito and CANdelaStudio support the new UDS
diagnostic protocol (ISO 14229), which DaimlerChrysler is introducing in all of its corporate divisions on each successive model change
beginning with the current C-Class where it will replace the previous
KWP2000 protocol. DaimlerChrysler is relying on the standard ODX-F
format for describing the flash data too. This is done with the flash
data management tool CANdelaFlash from the CANdela product line.
13:05 Uhr
Seite 5
In its diagnostic development process CLAAS runs through the VModel with the CANdela tool chain. CANdelaStudio is used to create
the specification of diagnostic functionality consistently. The captured data are used directly to generate the ECU-specif ic diagnostic
software component with CANdesc. To parameter ize the tester
CLAAS utilizes ODX data exported by CANdelaStudio, Figure 5.
For a half year now CLAAS has also been using CANoe Option DiVa
(Diagnostic Integration and Validation Assistant). DiVa makes it
possible to automatically generate and execute reproducible test
cases for implementation and integration of the diagnostic protocol. Serving as requirements are internal CLAAS test specifications
and the diagnostic database. Suitably configured, DiVa permits test
scenar ios of var ying depth and intensity, e.g. comprehensive tests
or just tests of specif ic services. The program outputs detailed
HTML test reports for error analysis purposes. In the future, automated testing with CANoe Option DiVa will be used for all CLAAS
ECUs.
Automating tests at har vesting machine producer CLAAS

At Europes leading producer of har vesting machines, CLAAS, ef ficient development of diagnostic systems plays a key role. In a combine har vester there are up to four highly complex bus systems optimized for agricultural tasks; see Figure 4.
The challenges facing the agricultural vehicle diagnostic system are
enormous: 350 connectors with 3,000 electrical contacts, 3,000 m
of copper lines, up to 25 ECUs or CAN nodes and numerous optoelectronic machine guards, potentiometers, valves, ser vo-drives
and speed sensors must all operate properly and work together.
Joint diagnostic project by DaimlerChrysler and Volkswagen

A joint project pointing the way to the future and simultaneously
serving as a test case for new diagnostic standards and exchange
formats was the joint development of the new transporter generation Sprinter and Crafter by DaimlerChrysler AG and Volkswagen
AG. The project executed under the name Phoenix started in the
year 2003 and reached its inter im conclusion in mid-2006. Technically, the Sprinter and Crafter vehicles are for the most part identical and will be produced in var ious body configurations, weight
classes and equipment var iants at DaimlerChrysler plants in Lud-
Figure 5:
Diagnostic development at CLAAS by the
V-Model using the CANdela tool chain.
3/4
09.02.2010
13:05 Uhr
Seite 6
VE HI CLE DI AG NOS TICS THE WHOLE STO RY
wigsfelde and Dsseldorf. Besides dif ferences in body design, other

key dif ferences lie in each vehicles brand-specif ic power train.
The initial idea for a diagnostic concept was to translate, so to
speak, the Sprinter diagnostic data from DaimlerChrysler to VW via
a central ECU in the Crafter. This would have made it possible to
omit adaptation to the VW service tester, since to a cer tain extent it
speaks a dif ferent language due to incompatible diagnostic philosophies. However, this strategy was rejected in favor of modifying
the service tester and exchanging diagnostic data by ODX. Stated in
somewhat simplified form, an ODX converter now processes the ODX
diagnostic data generated by CANdela and uses them to prepare the
ODX data for VW, Figure 6. Existing components of the VW service
tester are not replaced, rather they are supplemented by other
functions needed for a migration.
ODX: Trials passed successfully

In this first joint diagnostic project the par ticipating automotive
OEMs were able to acquire valuable experience, even though they
were confronted with dif ficult constraints. It was necessary to deal
with fundamentally dif ferent diagnostic philosophies involving dif ferent languages for coding, parameter ization and control. Fur thermore, all components contained in the diagnostic development
process, such as export to ODX and the ODX standard, were still just
in the development stage. Numerous internal departments and ex-
ternal suppliers were involved, there was as yet no practical experience with the new ODX standard, and a tight schedule had to be
maintained. In the Phoenix project the per formance of the ODX
standard was put to the test in a challenging large project and it
passed successfully.
Future visions: Where does the road lead?

With relentless progress in standardization many things are simplified, and it is possible to come to grips with new challenges. As ever, natural competition will generate a great deal of dynamism in
future development. Of course, it is impossible to predict exactly
what ef fects this will have on vehicle electronics and diagnostic
systems of the future. However it can be stated with cer tainty that
the signif icance of Internet technologies will continue to grow, as
is also the case in many other technological areas. For example,
Diagnostics-over-IP is conceivable. Initial studies with Ethernet
and TCP/IP are already under way in conjunction with FlexRay gateways. If vehicles take on the position and functionality of a HTTP
server from an information technology perspective, general identification via IP addresses might make sense, for example, and this
would make Vehicle Identification Numbers super fluous. Standardization will continue to advance in test modules and test procedures, and re-use in development, production and the service garage will become commonplace. Similarly, error messages in clear
text will become available on PCs and Web Browsers. Prerequisites
Figure 6:
Cross-OEM exchange of diagnostic data
between DaimlerChrysler and VW based
on ODX.
3/5
09.02.2010
for this are diagnostic design concepts with universal and automatic tool chains that can generate diagnostic data for all components,
from the modeling tool to the author ing system. Vector will help to
drive sustained development of these innovative concepts.
Literature:
[1] Khner, T.: 20 years of vehicle networking and diagnostics What do we
anticipate in the future?, Vector Congress 2006
[2] Schlingmann, N.: Specification Coding Test: Development of diagnostic software, Vector Congress 2006
[3] Johanson, D.: Introducing ODX diagnostics in a OEM joint venture project, Vector Congress 2006
[4] Rtz, C.: What is the market demand for diagnostic solutions?, Vector
Congress 2006
[5] Stimmler, S. and Rtz, C.: On a solid basis Ef ficient development of diagnostic functions in the automobile, Automotive Electronics 2/2005
Helmut Frank
(Graduate Engineer)is a Business Development Manager at Vector Informatik responsible for the Diagnostics product line.
Uwe Schmidts
(Graduate Engineer) is a Marketing Coordinator at Vector Informatik whose responsibilities include the Diagnostics product line.
3/6
13:05 Uhr
Seite 7
09.02.2010
13:05 Uhr
Seite 8
Vehicle
Diagnostics
Increase your Development
&GDJFODZFWFONPSF
ECU
Development
Distr. Systems
Diagnostics
ECU
Calibration
ECU
Software
Process
Management
In diagnostic development, benefit from solutions that span the

entire development process. Increase your efficiency and improve
your quality by using optimally tuned and coordinated tools.
The CANdela product family supports you by:
> Frontloading early high-quality specification of diagnostic
requirements at the beginning of the development process
> Single source principle Re-use of created diagnostic data in
all process steps
> Automated code generation, validation and test
> Diagnostic tester ideally configured for your area of application
> Open interfaces and data exchange, e.g. via ODX
Vector diagnostic tools help you to reduce the effort required
in specification and data supply tasks by a factor of up to 7*.
In automated validation, improvements by a factor of 4 to 20*
are possible depending on the project phase. The bottom line
is that you realize a maximum level of quality with a maximum
level of economic efficiency.
For more information: www.car-diagnostics.com/efficiency/
*Sources: Leading automotive OEMs and suppliers

70499 Stuttgart
Tel. 07 11 / 8 06 70-0
www.vector.com
Automatic validation of diagnostic services by use

of a diagnostic integration and validation assistant
For the first time, a fully automated test case generator has been introduced in diagnostics validation at General Motors
Europe (GME) Development. This article describes the introduction of this automated testing of diagnostic implementations based on the example of the new Opel Insignia. An electronically readable diagnostic specification forms the basis for
test generation. The article describes how the tool used CANoe.DiVa (Diagnostic Integration and Validation Assistant)
from Vector Informatik was integrated in the existing tool environment, and it addresses cost and time savings as well as
improvements to technical processes that were realized compared to conventional, manual validation at the Opel Corsa.
Introduction
One consequence of strong competition in the global automotive
market is that it is forcing a shortening of development cycles.
Another is that the complexity of the electronic networking architecture is continually increasing. Key goals in replacing conventional systems by electronically controlled systems relate to cost
reductions, a high level of safety and reliability as well as better
manageability. Despite all of the benefits, it must not be forgotten
that increased numbers of electronic components in vehicles can
increase the probability of electronics-related faults. Since reliability is an important criterion for customers when purchasing a new
vehicle, it is essential to introduce new methods that enable
mastery of this complexity, accelerate the development process

and guarantee proper operation of the installed ECUs. Particularly
in the area of diagnostic functionality provided by the ECU, it is
crucial that diagnostic services are correct. They transport information that helps mechanics in the service garage to quickly determine the cause of a fault and correct it. This information must make
it possible for the mechanic to decide which component is the
source of the problem and what needs to be replaced to restore full
operational readiness. If this is not assured, the result may be erroneous replacement of properly operating units [1], which causes a
rise in warranty costs and a decline in customer satisfaction.
The E/E architecture of the Opel Insignia consists of several Controller Area Network (CAN) and Local Interconnect Network (LIN)
3/8
09.02.2010 13:26:37 Uhr
bus systems [2, 3]. All bus systems are accessed via a central diagnostic port (DLC), see Figure 1. Communication is defined by a GMspecific protocol. This GM diagnostic specification is based on
KWP2000 [4] and the CAN 2.0A standard. It contains all diagnostic
services allowed for addressing an ECUs diagnostic system to
obtain diagnostic information. These services are then output by
the diagnostic tester to establish diagnostic communication. As
soon as a request is sent, the addressed ECU(s) react with either a
positive or negative response:
> Positive responses contain the diagnostic information requested
by the diagnostic device. If there is a lot of diagnostic information, the response may include multiple message frames.
> Negative responses contain a clearly defined Negative Response
Code, which gives information indicating the reason for the negative response. Negative Response Codes are given in accordance
with the GM Diagnostic Specification.
The received responses must enable technicians to determine the
cause for a fault, so that they can perform the right tasks to solve
the problem.
Therefore, the success of a fault correction in the service garage
depends considerably on the accuracy and precision of the data
output by the diagnostic system. Proper implementation of diagnostic services is essential in performing quick and professional
service or maintenance to the satisfaction of customers. Diagnostics also plays an important role in end-of-line testing: it is used to
program ECUs and assure product quality. That is why comprehensive validation of diagnostic functionality is absolutely necessary.
Validation process and tool environment at General

Motors Europe
In development of the Opel Insignia, GME introduced the DiVa tool
from Vector Informatik for the first time. DiVa automates generation and execution of diagnostic tests.
Figure 2 shows the tool environments for the Opel Corsa and
Opel Insignia. In both cases, CANoe [5] is used as a test tool. While
validation is largely performed manually in development of the
Corsa, in development of the Insignia the vast majority of testing is
covered by fully automated tests.
Figure 3 shows a typical diagnostic validation process for an ECU
performed by a test engineer at GME. Development of the ECU software is subdivided into several phases. At the beginning of an ECU
development, the focus is more on implementation of ECU functionality than on diagnostic services. The latter are then elaborated
and developed in subsequent software versions. As shown in Figure 3, with introduction of the Phase 1 (SWR 1) software version,
only a small number of diagnostic services are implemented. The
use of diagnostic software components at GME (CANdesc) has made
it possible to implement a portion of the diagnostic content early
at the start of development, and as a result it is integrated in the
ECU earlier (Figure 3).
The number of diagnostic functions to be tested grows with each
development cycle. Once all diagnostic services have been implemented, regression tests are performed (SWR 7). If no more faults
are reported in diagnostic services at that development stage, the
ECU is production mature in the execution of diagnostic services.
Figure 1:
E/E architecture
and diagnostic
communication on
the Opel Insignia
3/9
09.02.2010 13:26:37 Uhr
Since a test engineer normally tests a number of different ECUs

simultaneously, without adequate tool support it is impossible for
the engineer to perform the large number of tests necessary to
cover all of the implemented diagnostic services of the individual
software versions. As a result, only newly implemented diagnostic
services are tested in-depth, and test engineers perform representative regression tests for previously integrated individual services
based on their experience. By using a suitable automation tool,
more tests may be performed in validation while simultaneously
reducing effort.
Requirements for the validation tool

A tool for automated diagnostic validation must satisfy the following requirements:
> Seamless integration in the existing tool chain
> Transparency and reproducibility: The test engineer must be able
to track the executed tests and repeat them.
> Conformity to existing testing methods at General Motors: The
tool must support existing test methods. In the diagnostic area,
the GM Diagnostic Specification already defines mandatory test
procedures for GMLAN Diagnostic Services of the ECUs.
> Expandability by the test engineer
> Automatic generation of test cases: The specification must exist
in a machine-readable format to enable this.
From specification to test execution and report

evaluation
As shown in Figure 2, DiVa represents the link between
CANdelaStudio (diagnostic specification) and the proven validation
tool (CANoe). DiVa can be seamlessly integrated in the existing and
established GME tool chain. Test cases for checking the individual
services are automatically derived from the CANdela diagnostic
specification (CDD file). The generated code is based on the CANoe
programming language CAPL (Communication Access Programming
Language) and can therefore be examined at any time. If problems
occur, the test engineer can intervene in the automated test
sequence and troubleshoot their causes (transparency). Furthermore, CANoes logging functions enable traceability and evaluation
of the diagnostic data flow on the CAN communication level.
The following steps are necessary to conduct a test with DiVa:
> Select the ECU and its variant
> Configure the test
> Generate the test
> Add the generated test module to the CANoe test environment
> Execute the tests
> Evaluate the test report
The user can modify test constraints in DiVa at any time. Among
other things, the Intensity parameter is used to configure the
test contents, e.g. full test, quick test or good case test. In
addition, under Supported services the user can exclude certain
services from the test or modify data contents of the services under
Data customization (see Figure 4).
Figure 2:
Comparison of diagnostic validation
and tool environment on the Opel
Corsa and Opel Insignia
3/10
09.02.2010 13:26:38 Uhr
AUTOMATIC VALIDATION OF DIAGNOSTIC SERVICES BY USE OF A DIAGNOSTIC INTEGRATION AND VALIDATION ASSISTANT
Table 1:
Test execution
times for Opel
Insignia ECUs
In updating the diagnostic specification, i.e. the CDD file, DiVa

enables synchronization to the new specification while preserving
previously defined settings. From a technical perspective, DiVa generates CAPL code for the CANoe test module in order to test all diagnostic services supported by the ECU. To assure conformity to the GM
diagnostic specification, the DiVa extension maps the test procedures of the GM standard. The test generation process produces a
detailed description of the generated test cases, CAPL test codes for
the CANoe test module and the associated CANoe test environment.
Test execution and report evaluation

After the test has been generated, the user opens the generated
test environment in CANoe and starts the test. The test duration
depends on the complexity of the diagnostic specification and the
user-defined test scope that is selected, and it may vary from just a
few minutes to several hours (Table 1). At General Motors, the
CANoe test environment serves as a joint platform for test automation and simplifies reuse of existing GM test programs. For example, end-of-line flash test procedures are also programmed in the
CANoe programming language CAPL. To simplify analysis by the test
engineer, test reports are structured according to the GM diagnostic specification. Figure 5 shows a typical test report.
Test coverage
Automating the tests extends test coverage and simultaneously
shortens the time needed for test execution. The extent to which
DiVa covers the test procedures described in the GM Diagnostic
Specification is described below. The quality and number of generated test cases depend in large part on the completeness of the
machine-readable diagnostic specification (CDD file). All generated
tests are derived from it.
A total of about 350 test sequences are defined in the GM Diagnostic Specification. The test sequences cover both good case and
bad case tests. A large share (approx. 80 %) of the test procedures
are covered by fully automated tests in DiVa. An application-specific
user input is required for 45 (15 %) of the test procedures defined in
the GM Diagnostic Specification. In such cases, DiVa pauses test
execution and asks the user to put the ECU in the required state.
The remaining 5 % of test procedures are not supported by DiVa and
must be tested either manually or by other means. This includes
tests that would put the rest of the test procedure at risk (e.g. generate EEPROM errors and detect them) or would cause long-term
changes to the ECU (e.g. an ECU without calibration data).
Testing depth is further enhanced by including execution of
additional non-GM-specific test cases.
Figure 3:
Scope of diagnostic functions in
various phases of
ECU development
at GME
3/11
09.02.2010 13:26:38 Uhr
Comparisons made at GME between validation for the Opel Corsa

and for the Insignia conclude that DiVa shortens test execution
time enormously by predominantly automated execution of all generated test cases, Figure 6. Table 1 shows a summary of execution
times and the number of generated test cases for ECUs in the Opel
Insignia. Often, manual tests can only be performed sporadically
due to time demands. Therefore, test results largely depend on the
experience of the test engineer and the amount of time available.
At GME, DiVa enables both complete testing of ECUs per diagnostic
specifications and greater test coverage in all development stages.
Economic aspects and efficiency increases

When a tool is introduced, its economic benefit is a primary consideration. The new Opel Corsa is very successful on the market, and
there are no negative reports of diagnostically-related electronic
problems. That is why the manually performed validation process
on the Opel Corsa was selected as a reference project. In contrast,
on the new Opel Insignia, DiVa was being used as the primary tool
for validation of diagnostic services. It was used to automate a
large share of validation tests for the first time. For comparison
purposes, the study evaluated the time required for test execution
and evaluation in the validation phase, based on representative
ECUs. The values given are based on implementation level SWR 5,
Figure 3. Most services have already been implemented at that
point, and a large number of failed test cases had already been
captured. Figure 6 shows validation effort in hours for manual
testing on the Opel Corsa and automated testing on the Opel
Insignia.
By using DiVa, execution and evaluation times were shortened

considerably on the Opel Insignia compared to the Corsa. In the
studied case, 3- to 5-fold improvement was attained (Figure 6). In
particular, the time savings was enormous for ECUs with a large
number of diagnostic services. If one considers later development
phases such as SWR 6 or SWR 7, the time needed for evaluating test
results is reduced even further. This can be traced back to the
smaller number of failed test cases in the more mature implementation. This trend continues in each new phase up to the production
launch. The production ready ECU must not exhibit any defects;
consequently, the evaluation time is equal to the execution time.
In this stage of Opel Insignia development, depending on the complexity of the ECU, efficiency might be increased by a factor of
2040.
The cost of the new solution is low, since all that is needed are
licenses for DiVa. A user at GME who is familiar with CANoe can perform DiVa tests without prior training. Additional hardware is not
required for test execution, since DiVa utilizes the available CAN
infrastructure via CANoe.
Limitations on automatic of test case generation and test

execution
Even if automated tools are better than manual test strategies in
terms of test scope and time effort, automatic test generation does
run into limitations:
> Quality of the specification: Since the specification represents
the basis for generating test cases, completeness and accuracy
of the specifications are essential, i.e. a test is only as good as
its specification. Furthermore, there must be conformity to the
Figure 4:
Setting test constraints in DiVa
(here: configuration of services)
3/12
09.02.2010 13:26:38 Uhr
AUTOMATIC VALIDATION OF DIAGNOSTIC SERVICES BY USE OF A DIAGNOSTIC INTEGRATION AND VALIDATION ASSISTANT
Figure 5:
Automatically
generated test
report in DiVa
Figure 6:
Test effort per ECU
on the Opel Corsa
with manual validation, compared
to automated validation of diagnostic services on the
Opel Insignia
(execution and
evaluation time)
3/13
09.02.2010 13:26:39 Uhr
requirements of the General Motors diagnostic infrastructure

(GGSE-I) [6]
> Reproducibility: Due to the non-deterministic properties of CAN
communication in a vehicle, certain error situations are very
difficult to reproduce in testing.
> Secondary fault: In case of error, the automated test tool in
contrast to a test engineer cannot distinguish between an
initial fault and a secondary fault.
> User interaction: In application-specific tests it may be necessary to put the ECU in a state where additional hardware is
necessary. These cases cannot be handled fully automatically in
the approach described.
Summary
Without the use of test automation tools, it is hardly possible to
achieve the desired coverage in validation of the diagnostic functionality of modern vehicles any longer. CANoe.DiVa from Vector
Informatik has been adapted to GM requirements to support all
established test processes, and it fits seamlessly in General Motors
Europes existing tool chain. It is used as an automated test tool
for validation of diagnostic services on the new Opel Insignia.
With DiVa, GME is not only shortening test duration, but is simultaneously increasing intensity of testing by its ability to perform
regression tests more frequently. Furthermore, the scope of test
coverage is extended by executing additional non-GM-specific test
cases. In direct comparison to manual validation on prior successful projects, both technical and economical efficiency have been
increased significantly. Depending on the development phase and
quality of implementation, efficiency increases by a factor of 4 to
20 are realistic. At the same time, it is possible to satisfy the high
expectations of customers in terms of quality.
[1] Thomas, D.; Ayers, K.; Pecht, M.: The trouble not identified phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42,
P. 641-651, 2002
[2] LIN Consortium: LIN Specification Package Revision 2.1, OV. 2006
[3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991
[4] International Organization for Standardization: Keyword Protocol 2000,
ISO 14230, 1999
[5] Krauss, S.: Testing with CANoe, Application Note AN-IND-1-002. Vector
Informatik, 2005
[6] General Motors. GGSE ECU Diagnostic Infrastructure Requirements,
Version 1.07, 2007
Dr. Philipp Peti

studied Computer Science at the Vienna University of Technology. He earned his doctorate degree in Computer Science, also at TU
Vienna. Dr. Peti is a development engineer in
the Global Systems Engineering group at
General Motors Europe, located in
Rsselsheim, Germany.
Armin Timmerberg
studied Electrical Engineering at the University
of Applied Sciences at Wiesbaden. After his studies, he was first employed as a systems engineer
in the aftersales area at General Motors Europe.
His primary job was to implement ECU diagnostics in the GM Service Tester TECH2. Since 2004,
Mr. Timmerberg has been working as a development engineer in the Global Systems Engineering group at General Motors Europe, where he is
responsible for diagnostic validation.
Thomas Pfeffer
studied Electrical Engineering at the Darmstadt University of Technology. Mr. Pfeffer is
group manager for Diagnostics and Test
Automation in the Global Systems Engineering group at General Motors Europe, located
in Rsselsheim, Germany.
Simon Mller
studied Software Technology at the University of Stuttgart. As a product manager he is
responsible for CANoe.DiVa on the Vehicle
Diagnostics product line division at Vector
Informatik GmbH in Stuttgart.
Christoph Rtz
studied Computer Engineering at the University of Cooperative Education at Stuttgart. He
works at Vector Informatik GmbH in Stuttgart
as a global product line manager for the
Vehicle Diagnostics product line division.
3/14
09.02.2010 13:26:39 Uhr
Vehicle
Diagnostics
Automate Your Test Sequences in
Diagnostic Integration
Development
Distr. Systems
Take advantage of automated test sequences in your integration tests.

Option DiVa for CANoe lets you automatically generate reproducible test
cases for various regression and release tests and then execute them.
ECU
Test
You benefit from:

Diagnostics
ECU
Calibration
> Comprehensive test coverage in implementing diagnostics for an ECU

> Quick execution of test cases and generation of a clearly structured
test report
> Easy configuration of test contents
> Full integration in the Vector tool chain.
ECU
Software
These features help you attain maximum efficiency and quality in

integrating the diagnostic protocol in your ECUs.
Process
Management
More information: www.car-diagnostics.de/diva

70499 Stuttgart
Tel. 07 11 / 8 06 70-0
www.vector.com
09.02.2010 13:26:41 Uhr
A source code generator approach to implementing

diagnostics in Vehicle ECUs
Implementing diagnostic functionality in automotive ECUs is usually an expensive, time-consuming and inefficient process. Computer-generated source code based on ECU-specific diagnostic data can dramatically decrease costs and development time and increase quality and efficiency. By considering the weaknesses in the typical ECU diagnostic development
process, a clear set of objectives emerges. Defining a source code generation system that addresses these weaknesses lays
the groundwork for implementing a successful solution.
Introduction
Conventional diagnostic development process
It is common knowledge that the electronic content of automobiles

is increasing year by year. In order to take advantage of reusable
diagnostic software components, it is necessary to examine the
diagnostic software structure and identify the parts that are ECUindependent and the parts that are ECU-specific. The ECU-independent parts are reusable across different ECUs and can be written
once up front and deployed over multiple ECUs in multiple vehicle
programs that share common high-level diagnostic requirements.
The ECU-specific parts are not reusable across different ECUs in a
vehicle. This ECU-specific software will not fit the write-once-usemany model of the ECU independent software, but it can still be
done in a more efficient way through a source code generation process that automates as much of the ECU-specific software as
possible.
Most OEMs and suppliers work together in a common diagnostic

development process. This conventional diagnostic development
process is laden with inefficiencies that drive costs up and require
large efforts over several months to complete (Figure 1).
The process starts by setting up the requirements documents.
The diagnostic requirements are captured in a word-processor specification document. This authoring process requires a great deal of
time and effort and produces a document which is difficult to verify
as either complete or correct.
Once this document is completed, it is delivered to the supplier.
The supplier engineers must read and interpret the document. Less
experienced suppliers will not fully understand the requirements
on their own and will require significant support from the OEM
in getting up the learning curve. Opportunities for misinterpreta-
3/16
09.02.2010 13:26:52 Uhr
tion are everywhere and almost always lead to non-compliant

implementations. In this situation, not only non-compliant implementations are likely, but also come in the form of multiple suppliers having the same misunderstandings and producing the same
issues across multiple ECUs.
Once the ECU software is implemented and delivered to the OEM,
the OEM must test each ECU for compliance to requirements. Given
the process, the OEM has no choice other than to test each and
every requirement on each and every ECU. This means redundant
and parallel testing of all ECUs. These tests are likely to identify
failures that are shared by multiple ECUs. In the end, many engineers are all working to find and resolve similar issues across multiple ECUs.
Frequently, diagnostic functions are the last implemented in an
ECU. Without diagnostics, many basic ECU functional requirements
are difficult or impossible to test. As a result, the late availability
of diagnostics forces many tests to wait until the last minute, even
for functional requirements implemented early in the development
cycle. Postponing important testing dramatically increases the risk
of identifying significant issues very late in the development cycle
and putting program timing at risk.
Development engineers are left to learn and apply requirements
spanning numerous documents, from different organizations and
different authors; each with their own points of view, sets of terminology and levels of completeness. Incomplete definitions, ambiguous wording, inconsistent terminology and requirements that are
just plain assumed and not specified make the job nearly impossible to execute right the first time.
Figure 1:
Conventional diagnostic development process with
breaks in the data flow. The late implementation
results in a short integration and test phase.
In addition, suppliers must also deal with the possibility of

changes in diagnostic requirements from the OEM. These new documents not only mean reworks, but also further increase the opportunity for misinterpretation of requirements that can lead to
reworks of the reworks.
Diagnostic source code generator

From office productivity software to web applications, most modern software packages profit from including pre-built components.
This enables the engineer to focus on the core tasks of the specific
application and to reduce the overall complexity. This also appeals
to the project manager as the development proceeds faster and
risks are reduced. The diagnostic component approach has another
significant advantage. Different diagnostic specifications from different OEMs can share a common application-programming interface. This interface not only hides the complexity of the extensive
ECU-independent diagnostic specifications from the programmer,
but also keeps ECU application software design OEM-independent.
The OEM defines ECU-specific requirements as input data to the
source code generator. These formal requirements replace the current word-processing based documents used today as a basis for
software development. The source code generator creates an ECUspecific diagnostic software component according to the OEMs
diagnostic requirements. Next, the supplier develops the ECU-specific parts of the diagnostic software. The complexity of the diagnostic protocol is hidden by the application-programming interface
that connects the communication to the diagnostic functions in the
ECU.
Figure 2:
The diagnostic development process with the Vector
CANdela approach. Diagnostic data is stored in one
database and then reused in all subsequent process
steps.
3/17
09.02.2010 13:26:53 Uhr
Advantages from the OEM perspectives

The component developer manually develops a framework that covers all ECU-independent requirements. This is the same process
done today by any supplier and the OEM. The main difference is
that parallel and redundant efforts for implementation and testing
are eliminated. Redundant implementation errors are simply avoided.
This also eliminates common and parallel misunderstandings of the
diagnostic specifications. When the work is done and the component is ready for use, the same framework is shared by all suppliers.
The OEM must define ECU-specific requirements as input to the
source code generator. This formal specification of requirements
can be used for much more than just tailoring embedded software
components. It can be reused to generate a word-processor specification document and to generate input data to test systems. If an
appropriate tool supports the data entry process, the entire diagnostic process will be more efficient than it is today.
Another advantage of software components is their availability.
As the software component is typically ready for use at the beginning of product development, the very first implementation of the
ECU already contains diagnostics. This improves the quality of the
complete diagnostic implementation as late changes are reduced
or avoided completely.
Advantages from the supplier perspective

The supplier generates source code for all OEM-specific requirements. He does not need to interpret the OEMs diagnostic protocol
specification at all. Inconsistent interpretations and implementations of the protocol are left out of the process, which leads to a
significant reduction of development iterations.
The diagnostic component is typically available at the beginning of

the project. Because the components interface mirrors the functional requirements, any ECU-specific requirements are insulated from
OEM specifications. This means that ECU-specific source code can be
reused for other vehicle programs with other OEMs without significant modifications. This structure produces ECU application code that
is highly portable and not tied to a specific vehicle program.
Solution the CANdela approach with CANdesc

There is already a working implementation of this approach to implementing diagnostics in an ECU. CANdesc, a part of the Vector CANdela
product family, implements exactly this approach (Figure 2).
CANdesc works with FNOS, GMLAN, FIATLAN. and many more OEM
specifications CANdesc is applied in many ECUs in many real-world
vehicles.
CANdelaStudio is the authoring tool to define the ECU-specific
data. A use-case-oriented user interface provides an intuitive view
on diagnostic information and allows easy and comfortable editing. The CANdelaStudio data model covers all requirements necessary for effective source code generation as described in this document (Figure 3).
The source code generation tool outputs the ECU diagnostic software component source code (Figure 4).
Resource requirements are a very sensitive point in automotive
embedded software. CANdesc was designed with this point in mind.
Exact resource consumption depends on microcontroller and compiler selection and so does the optimal generation configuration,
but typical values according to real-world experiences are shown
here. Please note that these numbers represent a replacement for
the resources consumed in a typical diagnostic implementation,
not an addition to them.
Figure 3:
Generation of an ECU diagnostic
software component
3/18
09.02.2010 13:26:54 Uhr
A SOURCE CODE GENERATOR APPROACH TO IMPLEMENTING DIAGNOSTICS IN VEHICLE ECUS
> ROM: about 8 k for an ECU of moderate complexity (like a climate

control or transmission unit), about 5 k for even the smallest
ECUs
> RAM: about 128 bytes
The Vector CANdela approach shows that the concept of computer generated diagnostic software components not only works in
real world applications, but also delivers on the promises made by
such an approach.
The experiences with CANdesc are impressive. From the start of the
component generation and integration, all diagnostic services are
working in a few hours. Most of the features work right on the first
try and many features are running by the end of the first day. This
rapid development allows for a complete diagnostic implementation before the first bench delivery. The total diagnostic development time is reduced by up to 80 %, which corresponds to a savings
in effort of about 4 man months (Figure 5).
Conclusion
Diagnostic implementation is a significant part of the ECU development process. There are opportunities for significant gains in both
efficiency and quality. The malfunction detection strategies and
operational diagnostics strongly depend on an individual ECU
these tasks continue to be part of the ECU application. But the
ECU-independent part is a perfect candidate to be implemented as
a diagnostic framework.
To optimize the implementation, this framework must consider
ECU-specific data. The framework source code is to be generated by
a computer based generation tool, processing a formal description
of all diagnostic requirements. Moreover, this formal description of
diagnostic data has significant potential to simplify the complete
diagnostic development process. Generated specifications, documentation and tester data replace their hand-made counterparts of
the conventional diagnostic development process.
Figure 4:
From diagnostic specification to C-Code
Christoph Rtz
Dipl-Ing. Christoph Rtz (BA) studied
Computer Engineering at the University of
Cooperative Education at Stuttgart. He is
the global product line manager for the
Vehicle Diagnostics at Vector Informatik in
Stuttgart/Germany.
Figure 5:
Effort savings with the CANdela approach
3/19
09.02.2010 13:26:54 Uhr
09.02.2010
13:14 Uhr
Seite 1
ECU Software for Dry Dual Clutch has Stringent Requirements

Integrated Diagnostic and Flash
Solution with Script Control
Dual-clutch transmission technology not
only of fers signif icant improvement in
driver convenience and ride comfort at
moderate added cost. At the same time,
it also delivers excellent fuel economy.
The design of a production version of the
worlds first dry system dual-clutch
transmission represented a special challenge for the ECUs electronics. Frequent
flashing of the ECU is necessary in the
development process, and this requires
the use of rational flash methods and
high-per formance tools that are up to
the task.
Automated transmissions combine the convenience of an automatic

transmission with the cost advantages of manual transmissions. In
conjunction with ECM (Electronic Clutch Management), dual clutch
transmissions form the basis for modern drive concepts. While the
ECM system handles electric motor actuation of the dual clutch,
transmission control ensures that two gears are always engaged simultaneously. Usually gears 1, 3 and 5 are served by one transmission section, while the other section is responsible for gears R, 2, 4
and 6. Disengagement of one clutch and simultaneous engagement
of the other clutch enables a nearly jolt-free gear shift without an
interruption in the propulsive force to the next higher or next
lower gear. The optimized shifting method requires just a few hundredths of a second to shift gears and of fers better fuel economy
than manual shifting.
Until now, dual-clutch transmissions were only available in wet

technology, i.e. with components running in oil. Although they of fer the advantage of greater power loss absorption by oil cooling,
this is contrasted by the disadvantages of a lower friction factor
and a larger drag torque when idling. Since LuK uses electric motors to actuate the dry dual clutch, this of fers even greater potential for reducing fuel consumption and CO2 emissions.
Greatest Ef ficiency with Dry Dual Clutch

The first dry dual clutch was developed at the facilities of automotive supplier LuK in Bhl (Figure 1). This company, part of the Schaef fler Group and a specialist in clutch and transmission component
solutions, has contributed to the advancement of automotive technology with all sorts of innovative developments. In 1965 it was the
first company in Europe to introduce the diaphragm spring clutch
to the market, and in 1985 the first dual-mass flywheel. This was
later followed by CVT (Continuous Var iable Transmission) components for torques greater than 300 Nm and the worlds first electromechanical automatic transmission. Meanwhile, every fourth car in
the world is driven with a LuK clutch. Today, the focus of the companys development is on alternative drive concepts too, such as
components for dual-clutch transmissions and hybrid drives.
3/20
Figure 1:
The core of the modern dual-clutch transmission: Dry
(left) or wet (right) dual clutches ensure gear shifts
without inter ruption of tractive force. Software development for these drive concepts by LuK required frequent flashing.
Intelligent Software protects the Clutch System

A problem specif ic to the dry clutch becomes apparent when stopping on a hill, when the driver applies the braking torque via the
gas pedal and clutch instead of the brakes. Due to poorer cooling,
the clutch gets hot much quicker than in a wet system. To protect
against premature wear and failure, intelligent driver warning
strategies are required, which support the driver in optimally utilizing the clutch. The software might achieve this, for example, by allowing the vehicle to slowly roll free after a short period of time,
which induces the driver to automatically step on the brake pedal.
Dur ing the drive, the electronics must adjust the clutch engagement to be quicker or slower depending on vehicle speed, gas pedal
position, etc.
Overall, numerous constraints and parameters need to be considered in automatic clutch operation, and they change dynamically
dur ing operation. The clutch heats up, cools down again and is therefore continually changing its character istics. The electronics must
continually adapt the behavior of the automatic dual clutch to these changing parameters. LuK utilizes an advanced computational
model that yields a clutch mechanical design that is less complex
and is therefore more economical for the automotive OEM.
09.02.2010
13:14 Uhr
Seite 2
From in-house Flash Tool Development to universal Flash

Solution
At first, LuK handled the flashing that is frequently needed in software development (updating of program code or data in the ECUs)
with an in-house development that was even used to flash production ECUs. Independently, the clutch specialist conducted a search
for a diagnostic tool for CAN. After finding, dur ing a test phase,
that other products were lacking in var ious areas ranging from
the graphic user inter face to product support LuK decided on
CANdito from the Stuttgart-based company Vector Informatik. Vector impressed them with a solution that can implement all of the
var ious flash methods and can also serve as a full diagnostic tester
(Figure 2).
In the diagnostic tester CANdito, the LuK employees found precisely what they had been looking for, and more. The tool enables symbolic access to all data and functions that are accessible via the
diagnostic protocol. It reads in ODX-2.0 description files and supports scripts for automating diagnostic and operating sequences.
ECU var iants are automatically detected. The author ing tool
CANdelaStudio is used to describe the diagnostic data in CDD and
ODX formats. Each ECU is described in a separate document that is
based on a document template. A var iants concept makes it possible to define the commonalities and dif ferences of an ECUs var iants, largely without redundancies. Full parameter ization simply
Figure 2:
By using the right tool
and ODX, a smooth transition of flash processes
is possible from development to production.
3/21
09.02.2010
13:14 Uhr
Seite 3
involves reading in the ECU description file. All communication parameters and all existing services and data are immediately available. In a separate work step, the embedded software can also be
generated from the description file. This ensures that the diagnostic description, the software in the ECU and parameter ization of
the diagnostic tester are always coordinated.
whether an update is even necessary. Scripts ensure that the tool

always uses the right software for the par ticular hardware var iant,
even when the same ECU hardware is used on numerous dif ferent
vehicle models. Use of CANdito as a diagnostic tester and flash tool
including script functions to simplify the job goes a long way
toward improving process reliability.
Diagnostics and flashing with one Tool
Outlook
A key basic requirement for LuK is that it must be possible to read

out the software currently in the ECU before flashing. This is necessary to ensure that the correct software version is being flashed in
the relevant ECU. Fur thermore, this capability is impor tant for
reading out system parameters and the error memory or for making
before/after compar isons. In the old solution, the diagnostic tester
was needed to access these data. After the user had read out the
necessary data, the user would stop the tester, start the flash tool
and select the appropriate files an intricate procedure.
A remedy to this situation was found in use of the script language
integrated in CANdito (Figure 3). After communication has been established, the tool reads out the identification of the software currently in the ECU. Based on a table, the tool autonomously decides
Current trends in reprogramming memory chips include: ODX-F, parallel flashing and flashing with increased bandwidth via FlexRay. In
light of these wide-ranging trends, questions related to protection
of investment and assurance of future coverage are thoroughly justified. Users of Vector products benefit here, not only because they
represent a scalable tool chain with multiple flash solutions, but also because they of fer timely program versions that meet current
standards. While ODX-F support and parallel flashing are already
available, FlexRay support is already coming with the next release.
Existing author ing tools for the development of diagnostic parameter ization or the ODX-F flash containers round out this area.
Werner Schmitt
Electrical technician, works on developing
electronic systems in the transmission automation area at LuK GmbH & Co. oHG. He is
responsible for diagnostics as well as startup and service of these systems.
Andreas Patzer
(Graduate engineer) works at Vector Informatik GmbH where he is Business Development Manager in the Measurement and Calibration product line.
Figure 3:
LuK develops flash jobs using the script editor integrated in CANdito. In the scripts, diagnostic functions
are executed, and the necessary infor mation and data
are read-in from an ODX flash container.
3/22
09.02.2010
13:14 Uhr
Seite 4
3/23
09.02.2010
13:14 Uhr
Seite 1
Flexible Flash Solution for every Job

Open standards enable use of gener ic tool chains
Reprogramming of modern flash chips has become a
commonplace process in development and production.
In practice, the jobs are exceptionally diverse depending
on the ECU, department, manufacturer and supplier so
preparation, management and the flash process itself all
involve considerable ef fort. Therefore, this ar ticle first
sur veys the purely technical terrain in which flash solutions occur. Afterwards, the perspective is expanded to
cover process-oriented jobs and rational approaches to
solutions.
Memory fundamentals
Wherever information needs to be saved for a cer tain period of
time, one finds rewritable flash memory in use today, e.g. in USB
sticks, digital cameras and mobile telephones. Long-term storage
of the firmware of microcontroller-based ECUs in the automobile is
a frequent application area for flash memory. The market of fers
var ious flash architectures as NAND or NOR flash, which dif fer in
terms of control logic, access speed, current consumption and life.
Common to all types is that the memory needs to be erased before
rewriting. Although data can be read-out byte-by-byte, the erasing
process in contrast to conventional EEPROM memory can only be
per formed block-wise. In ECUs, NOR flash is used almost exclusively.
Technical flashing
Technical flashing essentially refers to a process for updating
program code and/or data in ECUs. This may be done, for example,
using a PC or laptop with special software the so-called flash tool
via the existing network infrastructure, e.g. the CAN serial bus
system (Figure 1). Requirements dif fer, sometimes signif icantly, for
flashing dur ing the development phase, end-of-line programming
or software updates at service centers. While software changes in
the development phase always involve providing new code or new
data to the same ECU, what matters in production-related flashing
is to use from a wide variety of released software levels those
that are correct for the specif ic vehicle and its features. In this
case, it is essential to consider the vehicle var iant, installed features, country code, serial number, safety aspects, etc.
At a minimum, the following components are needed for flashing:
> Flash data,
> Flash tool,
> Flash bootloader, which is integrated in the ECU and executes the
actual erase/write processes
> The necessary meta information.
3/24
Figure 1:
Memory structure in ECU with FlashBootLoader
from Vector.
The flash data contain the program code and specif ic parameter
sets intended for the ECU. The flash tool implements the flash routine on the PC side. If the tool only supports a special flash routine,
then dedicated flash tools may be needed for dif ferent flash jobs.
Data-driven, multipurpose flash tools are ef ficient and more modern. Flash job control enables their use for dif ferent ECUs and flash
routines, e.g. if the same ECU is to be used at dif ferent OEMs. A single dedicated tool is all that is needed to manage flash jobs and associated flash data in containers, and it always has the same user
inter face.
Responsible for the routine on the ECU side is the flash bootloader
(FBL) that is integrated in the ECU and is always active. The FBL is
par titioned into the permanent bootloader existing in the ECU and
the flash driver. For security reasons, the flash driver is only temporarily loaded in the ECUs RAM, since among other things it contains the service for initial erasure of the flash memory, acceptance
of data from the flash tool and execution of the subsequent reset.
The bootloader consists of the CAN driver, transport protocol and diagnostic layer and thereby ensures that the ECU always remains addressable, even if the flash process could not be completed properly.
09.02.2010
13:14 Uhr
Seite 2
CAN drivers, CCP/XCP protocols, etc. A generator tool is responsible

for data configuration and generation of the header files.
If one utilizes a suitable author ing tool to conveniently generate
diagnostic data and services, the tool can be used to directly parameter ize the diagnostic tester and generate the relevant diagnostic code for the ECU. An ODX-D data container stores the diagnostic data and flash job together. There is an ODX-F management
and author ing tool for linking flash data, jobs and meta-data. The
associated communication parameters are not contained in the
ODX-D container, rather in a dedicated ODX-C container ('C' stands
for Communication), Figure 2.
Process-oriented flashing
A special challenge in flashing is to always load the right application in an ECU. That is the only way to ensure complete and errorfree functionality in the vehicle. In production-related flashing,
meta-data are required for this, such as ECU and vehicle var iant,
software serial number, name of the flash job and much more. Data
container files, which are referred to here as flash containers, are
appropriate for consistent management of this information together with the flash data and flash jobs. ODX (Open Diagnostic
data eXchange) is available as a standardized format, wherein a
distinction is made between ODX-D for diagnostic-relevant information and ODX-F for flash-specif ic data.
Since meta information is generally unavailable in development,
flashing is of ten very dif ferent dur ing development and dur ing production. So ECU developers sometimes flash not via the diagnostic protocol, but via CCP (CAN Calibration Protocol) or XCP (Universal Measurement and Calibration Protocol).
Rational generation and management by tools

To generate the executable flashable binary files via compiler/linker, one needs the source code for the application, diagnostic code
and embedded code elements, which are supplemented by checksum information, fingerprints and other data. Use of a comprehensive product solution quickly leads to the desired results e.g. one
from Vector Informatik with source code for the embedded por tion
in the ECU, consisting of operating system, network management,
Figure 2:
Based on the ODX-F container, the flash routine is
executed fully automatically with CANape, CANdito
and CANditoFlash. The container contains all necessary
data and infor mation such as reference to the flash
file, flash job and meta infor mation.
3/25
09.02.2010
13:14 Uhr
Seite 3
Figure 3:
Use of the ODX-Standards enables a
smooth transition in flash processes from development to production.
Getting a grip on references

Later in the flash process the system reads from the ODX-F file the
flash files, meta information and reference to the flash job being
used. The latter is found in the diagnostic description, from which
it is loaded and executed. References are used to produce the relationships between the ODX-F, ODX-D and ODX-C containers.
On the one hand, references to flash data and flash jobs are easy to
replace without requir ing regeneration of the ODX files, but they
are also associated with the risk that the process will no longer
function if a referenced document is missing. One solution to this
problem was to create meta containers that save all associated
data in a single, compressed file. By def inition, the containers
with the 'PDX' (Packaged ODX) extension do not permit any references to files outside of the container.
This concept ensures that one always loads the right flash data with
associated meta information into the ECU by the proper flash routine. Fur thermore, it permits both fully-automatic and semi-automatic flashing. Fully automatic means that the user does not per form any configuration or selection activities. In semi-automatic
flashing the user can influence the flash process.
Summary
The use of standards such as ODX enables the use of tool chains that
ensure reliable and process-conformant flash processes in every development phase (Figure 3). Gener ic and data-driven tools benefit
3/26
the user by of fer ing enhanced flexibility with the goal of cover ing a
wide variety of requirements and job tasks related to flashing.
Flash routines cannot be implemented without suitable tool chains.
From Vector the ECU developer gets universal tool support in all
aspects of flashing: CANdelaStudio for specifying diagnostic
requirements and generating the CDD, ODX-D and ODX-C files,
CANdelaFlash for generating the ODX-F flash containers and the
flash bootloader for a wide range of controllers. As author ing and
development tools, CANape and CANdito are used to generate
script-based flash routines, and they also form the actual runtime
environment for the flash process. CANditoFlash serves as a pure
runtime environment for flash processes generated with CANape
and CANdito.
Andreas Patzer
(Graduate engineer) is employed at Vector
Informatik GmbH as Business Development
Manager for the Measurement and Calibration product line.
09.02.2010
13:14 Uhr
Seite 4
Vehicle
Diagnostics
ODX at the press of a button! Rely on
proved and tested ODX solutions
Development
Distr. Systems
ECU
Test
Diagnostics
ECU
Calibration
ECU
Software
Process
Management

70499 Stuttgart
Tel. +49 711 8 06 70-0
www.vector.com
In your ODX development, you can benefit from the know-how

of our employees and our comprehensive experience acquired
in production projects and ODX standards committee work. Take
advantage of Vectors universal ODX products and services:
> Create diagnostic data easily and exchange this data with
your process partners
> Diagnose individual ECUs or the total vehicle
> Flash ECUs based on ODX-F data
> Migrate master data to ODX
> Benefit from our consultation in implementing and
integrating ODX
Add ODX to your diagnostic development reliably and quickly.
Vector tools and services will support you in all phases.
Press the button! www.odx-solutions.com
o
Indig
ics
New:
gnost
ia
d
le
ic
h
ve
X
Easy
on OD
based
Tool
09.02.2010
13:04 Uhr
Seite 1
Flash programming via CAN

requires suppliers exibility
By Peter Liebscher (Vector Informatik)
lot of flexibility is demanded of automotive

suppliers in the development of electronic components. This also applies to
the area of Flash programming. Constraints in the
various phases of the product life cycle, which in some
cases may vary widely,
each require differentiated
handling. Besides realizing
new optimization potential
by their own inventiveness,
suppliers now also have
more powerful tools available to them.
ECUs need to be reprogrammed and analyzed
more or less frequently over
the various phases of a vehicle ranging from development to production to operation in the target vehicle
to diagnostic analysis of returned product. Once the
ECU has been installed in
the vehicle, CAN is the only
means of accessing it. In the
development phase too the
CAN bus is utilized as an interface for exchanging software. For suppliers the basic challenge is to achieve
the most rational flow in
their own development and
production phases and satisfy the (strict) requirements
of the vehicle OEM.
The solution approach
of the company Continental
Automotive Systems (www.
conti-online.com), for example, involves creating their
own OEM-specific Flashloader for development and
production phases and a
customer-specific
Flashloader for the product operation phase. The production
boot-loader is optimized for
standardized in-house flash
processes and is decomis-
3/28
22
sioned at the end of the production process, so that in

normal operation only the
FXVWRPHUV )ODVKORDGHU LV
still active. For the supplier this eliminates potential
compatibility problems between the production bootORDGHU DQG WKH FXVWRPHUV
flashing process.
Since the topic of security plays an important role
in Flash programming in the
vehicle operation phase, all
security mechanisms for integrity, authenticity, copy
protection, etc. come into
play here. These aspects
are gaining in importance,
because Continental has
the capability of reactivating
the production boot-loader
to analyze returned product. Therefore, in reactivation precautions are taken
to ensure that unauthorized
persons cannot exploit this
indirect path to manipulate

or spy data.
A specific application
at Continental involves reprogramming a multiprocessor system with master and
slave controllers and external sensors. The master
controller can be flashed directly by CAN; however the
slave and sensors can only
be addressed indirectly in
flashing. To gain control over
the entire Flash process
given the described constraints, the Stuttgart-based
company Vector Informatik,
a specialist in developing
automotive electronics, was
hired to implement a special
extension. This extension is
capable of utilizing the serial IPC (Interprocessor Communication) connection between the master and slave
in Flash programming. In
this project a Flash tool with
Source: CAN Newsletter, CAN in Automation
a hard-coded Flash procedure is still employed, but

the future belongs to flexible
standard tools with which
the numerous challenges
of the Flash process can be
managed much more rationally at the supplier. The advantage of parameterization
using tools such as CANape
and CANdito from Vector is
that all information relevant
to the Flash process can be
saved in standardized flash
data containers. Use of the
ODX Flash format as a future de-facto standard enables data exchange with
other tools. At the same time
required diagnostic data are
stored in the container that
might be generated with the
CANdelaStudio program of
the same producer.
peter.liebscher@vector-informatik.de
09.02.2010
13:04 Uhr
Seite 2
3/29
AUTOMOTIVE
9. 2 0 0 6
09.02.2010
13:17 Uhr
Seite 1
INTERVIEW
Use of XCP on FlexRay
at BMW
Th i s fa l l t h e fi rs t F l ex R ay p ro d u c t i o n
a p p l i c at i o n w i l l h i t t h e s t re e t s . Th e
M u n i c h - b a s e d a u t o m o t i ve m a n u fa c t u re r
B M W i s i n t ro d u c i n g t h e i n n ovat i ve b u s
s y s t e m fo r t h e fi rs t t i m e o n i t s n ew X 5
ve h i c l e . F ro m D e c e m b e r 2 0 0 4 t o Ja n u a AdaptiveDrive in the new X5 utilizes sensors and performs computations to acquire data on vehicle speed,
steering angle, longitudinal and lateral acceleration,
body and wheel accelerations as well as their heights.
The swivel motors of the stabilizer bars and electromagnetic valves of the shock absorbers are controlled
based on this information.This provides full-time control of body roll and damping based on the given driving situation.The new BMW X5 is the first vehicle in
the world to utilize FlexRay technology.
r y 2 0 0 6 t o o l p ro d u c e r Ve c t o r I n fo r m at i k
wo rke d t o g e t h e r w i t h B M W o n t h e
F l ex R ay s o l u t i o n . F l ex R ay ex p e r t s M a r t i n Pe t e rat z i n g e r a n d F l o r i a n S t e i n e r o f
B M W a n d R o e l S c h u e r m a n s o f d eve l o p m e n t p a r t n e r a n d s o f t wa re p rov i d e r
Ve c t o r d i s c u s s e d t h e i r ex p e r i e n c e s i n
H A N S E R a u t o m o t i ve .
Mr. Peteratzinger, why FlexRay and why now?

Peteratzinger: That was a strategic decision. We have already reached the limits of reasonable bus loads with CAN,
and would otherwise need to install multiple CAN buses,
and not just for high-end products. Our analyses indicated
that up to eight CAN buses would be needed for just the
powertrain and chassis areas in the next 7-series car. But
we do not want to implement even more sub-buses; at
some point they become unmanageable. Therefore, some
years ago BMW decided to build up its development experience with FlexRay. We now have a foundation for future
electrical systems and will expand them to include additional vehicle systems in upcoming car models. If we did not
start on this now, we would have had to utilize a large number of CAN systems and sub-buses to carry us through, and
this would last for many years due to the development
cycles for car models.
Steiner: Another criterion of course is transmission rate. In

the current application sensor signals are acquired and processed both by the central ECU and by the satellites. On
the one hand, this decentralized approach leads to an increased demand for communication, and on the other hand
shorter cycle times are needed on this and future architectures due to their separation of sensors, control system and
actuator. In addition, many of the new functions and architectures place stricter requirements on real-time capability
and communication availability. This can only succeed with
a bus system like FlexRay.
Translated by Vector Informatik

4/0
Why did BMW chose suspension control as a pilot

application?
Peteratzinger FlexRay is a completely new development,
and we had no knowledge base from other production projects. In this case, the first step was to build up this knowledge. It was therefore important for BMW to be able to quikkly apply this acquired knowledge and implement necessary changes during development. In a system such as an engine controller the adaptation effort would be considerable due
to the large number of interfaces. This new suspension
system has a well-defined and limited functionality. In a small
team, together with our ECU suppliers and development
partners such as Vector, we were
able to make decisions and introduce modifications over short
decision-making paths. Furthermore, aspects of this application
made it possible to implement
many new FlexRay features
meaningfully.
When did you decide to eliminate CAN entirely as a fall-back
solution in this project?
Peteratzinger: That was done in a
relatively early phase of the project in the summer of 2004. After
we had successfully started up
FlexRay as a bus system to network the five ECUs in a stable
manner and had all identified and
assessed unresolved risk issues,
Martin Peteratzinger, Graduate

Engineer (University of Applied
Sciences), develops electronics
in the vehicle dynamics area of
the BMW Group and has functional responsibility for the
FlexRay application.
09.02.2010
13:17 Uhr
INTERVIEW
VECTOR'S CANAPE
Seite 2
AUTOMOTIVE
9. 2 0 0 6
l2
basic definitions. Part 2 of the document describes the XCP command set as a bus-independent protocol layer. Whenever a new Transport
Layer is added, as is being done now with FlexRay, a Part 3 document is created.
What does all this discussion about dynamic
bandwidth control really mean?
Schuermans: A part of the XCP on FlexRay specification defines dynamic bandwidth control.
Since the XCP protocol is essentially a MasterSlave communication protocol, the XCP Master
can distribute XCP Slots to individual Slaves
depending on how much bandwidth the Slave
needs. Dynamic bandwidth management requires that the Master knows which slots are available for this purpose. That must be a part of the
FIBEX file.
Optimization of ECU parameters with CANape
the decision was made to eliminate CAN altogether beginning with the next hardware level. In the process this raised the question: How would we calibrate the application?
Initially calibration was still performed via CAN, but in the
end this fall-back level was dropped. Therefore we first
developed a CCP-CAN-FlexRay gateway that converts CCP
messages to FlexRay and in the reverse direction too. In
the ECUs we also restructured the CCP module for FlexRay. This made it easier to continue utilizing CANape with
CCP (CAN Calibration Protocol). But that too was just a transitional solution, since first it is necessary to create such
gateways, and then they need to be maintained for a number of years. Therefore it was important to find a product
that would not just work exclusively in one project, but
would be available to the entire market. In the ASAM working committee XCP on FlexRay was driven by Vector with
the support of BMW and attained specification status in
February 2006.
Schuermans: Technically we had gotten a handle on the

measurement & calibration via XCP on FlexRay concept
relatively quickly. For Vector though it was clear that we had
to turn XCP on FlexRay into a standard as quickly as possible. ASAM has been working on XCP for quite a long time
now. XCP itself was finalized in 2003. The aim of the standard is to only require adaptation of the underlying transport protocol. The specific solution needs at BMW allowed
us to implement both the XCP stack in the ECU and on the
tool side CANape as the XCP Master very quickly.
XCP on FlexRay was standardized in February. What
was involved in this process?
Schuermans: Of course the work in ASAM requires a certain amount of time: First a project application is submitted,
then a working committee is formed, and finally a draft is
developed. XCP is split up into several subdocuments. Part
1 is an overview of the protocol family, XCP features and
Why is that good?

Steiner: Compared to the potential bandwidth
of FlexRay the current bus load is still very small.
We therefore had the luxury of making three XCP slots available to each ECU: One to communicate from
CANape in the direction of the ECU, and two to
send measurement data from the ECU in the
direction of CANape. That means that 15 slots
are used just for XCP. In the next car models the
bus will be utilized more intensively with more
ECUs. Then we will no longer have this freedom. All Florian Steiner,
ECUs must then share one Graduate Engislot or just a few slots for neer (University
XCP.
of Applied ScienThe only limitation here is ces), develops
that it will no longer be pos- electronics in the
sible to calibrate all ECUs vehicle dynamics
simultaneously. However, area of the BMW
this is of no consequence in Group and as a FlexRay devepractice, because devel- lopment expert he is responopers generally only calibrate sible for production-level ECU
their own ECU. With dyna- development.
mic bandwidth allocation this
can be done very quickly.
That is XCP will remain in the ECU?
Steiner: Yes! Although there is no need for direct measurement on the FlexRay bus while it is in service, the XCP
module will be retained in production versions of the ECU.
Diagnostics of the FlexRay ECUs is performed via OBD, the
standard diagnostic interface in the vehicle. XCP plays a
central role in testing and validating ECU functions and is
therefore a component of the production software.
Doesnt that pose a risk? Certainly there are people
who might want to reprogram the chassis.
Schuermans: XCP, and I am not just referring to XCP on
FlexRay here, has a so-called Seed&Key security mechanism. XCP is of course based on a Master-Slave principle.
4/1
AUTOMOTIVE
09.02.2010
13:17 Uhr
Seite 3
INTERVIEW
9. 2 0 0 6
The Master must ask the Slave for a "Seed",

and this is used to compute an associated
key. The Master does not grant the Slave
access until the correct key is obtained.
Roel Schuermans, Graduate Engineer, is

Senior Product Management Engineer at
Vector Informatik for the Measurement &
Calibration product line. As an expert in
the FlexRay protocol he has been involved
Peteratzinger: Our hardware supplier has

also installed another software protection
mechanism. So protection is twofold.
in the development of XCP on FlexRay in

the ASAM working committee up to its
standardization and worked on its implementation in CANape.
What did Vector bring to the table as a

partner with FlexRay?
Peteratzinger: Important was this We need
to measure and calibrate signals internal to
the ECU. It might have been possible to turn to other suppliers for a solution. In this context there were many open
issues. During HANSER automotives FlexRay roduct Day

in 2004 we met with experts from Vector, discussed these
issues and formulated our requirements. Although no standard existed yet at that time, Vector showed great interest
in working with us, and wanted to implement a solution for
us based on XC on FlexRay and then make it an official standard in the ASAM working committee. It was also a good fit,
because Vectors CANape product was already being used
in the existing BMW tool environment, and this meant that
our developers already had experience with this tool.
Mr. Peteratzinger, in retrospect what is your assessment of this joint effort?
From our perspective the collaboration with Vector was
very good. Vector handled most of the standardi ation work
and the first implementation. So I would like to express my
sincere thanks to Vector Informatik. Calibration of ECUs
with CANape and the XC Stack performed flawlessly from
the start, requiring just minimal modifications.
Application of suspension control system with CANape

as the XCP on FlexRay Master
automotive
F I R S T F L E X R AY A P P L I C AT I O N AT B M W
4/2
The application is an active suspension control system. Each of
A special measurement and calibration protocol is needed for this
the four shock absorbers has a valve with dedicated electronics
XC on FlexRay. In efforts toward the standardi ation of XC on
to control it. The valve is able to generate different damping
FlexRay in February 2006, Vector helped to give shape to its fun-
properties, since its continuously variable aperture determines
damental principles on the ASAM working committee and imple-
how much and how quickly shock absorber oil is pushed from
mented an application concept in the Vector measurement, cali-
the upper oil chamber to the lower one. The central control
bration and diagnostic tool CANape. This solution provides access
module is interconnected with the damper modules, the so-cal-
to all relevant ECU parameters over the FlexRay bus.
led satellites, via FlexRay. Different than in previously imple-
The ECUs of the suspension system transport all functional con-
mented suspension systems, while driving the vehicle the
trol data in the static area of the FlexRay protocol. Although XC
shock absorber characteristics can be independently adapted
communication is by definition allowed in both the static and
to the specific driving situation at all wheel suspensions. The
dynamic areas, BMW only utili es the dynamic area of the Flex-
satellite electronics controls excitations at the individual
Ray protocol for XC . It is also used for non-time-critical network
wheels, while the central ECU with its higher-level algorithms
management messages and the Transport Layer mapping of
monitors the overall effect on the chassis, and its control
FlexRay (i.e. diagnostics, coding, flashing). Due to strict time
system intervenes when pitching or rolling movements occur.
requirements of the control functions, the cycle time is 5 ms.
Direct access to internal ECU parameters is necessary to tune
Scheduling is not just set for the currently implemented applica-
the suspension system in driving trials and to assure system
tion, it will also be applied in precisely the same form in the next
functions in system integration.
planned vehicle startups at BMW.
09.02.2010
13:17 Uhr
Seite 4
ECU
Calibration
:PVSFGDJFOUBMMSPVOETPMVUJPOGPSNFB
TVSFNFOU DBMJCSBUJPOBOEEJBHOPTUJDT
Universal tool support simplifies your calibration of ECUs. The
versatile CANape tool lets you cover all application cases effortlessly:
ECU
Development
Distr. Systems
Diagnostics
ECU
Calibration
> Quickly and reliably capture measured data from various

sources synchronous and time-precise. Whether via CCP,
XCP-on-CAN/FlexRay/Ethernet or from external test
equipment
> Conveniently calibrate the parameters of your ECU algorithms, either online in the ECU or offline in the Hex file
> Easily manage large amounts of calibration data with full
traceability at all times even on large project teams
> Simplify your tool environment by seamlessly integrated
diagnostic services and flash solutions
> Benefit from a universal tool chain with extensive rapid
prototyping capabilities and MATLAB/Simulink integration
ECU
Software
Process
Management
Vector supports you from functional development to production-ready ECU, in the laboratory, on the test bench and during driving trials.
Information and downloads: www.ecu-calibration.com

70499 Stuttgart
Tel. +49 7 11 8 06 70-0
www.vector.com
XCP-on-FlexRay at Audi
AUTOSAR-compatible XCP software modules for FlexRay ECUs
To adjust parameter values in FlexRay ECUs, Audi calibrates them via XCP-on-FlexRay. One of Audis requirements was
AUTOSAR compatibility of the XCP embedded software modules in the ECUs. For this purpose Vector modified both the XCP
master and slave software so that Audis electronic developers could perform efficient measurements and calibrations.
This was possible thanks to dynamic allocation of the XCP bandwidth for FlexRay.
Starting in 2009, Audi will be implementing the FlexRay communication bus on its next generation of sporty luxury limousines. Since
FlexRay compared to CAN offers a significantly greater bandwidth of 10 MBit/s. Many electronic chassis and driver assistance
systems are connected to this deterministic and time-triggered bus
system. For Audi developers, this decision meant that several thousand parameters needed to be directly parameterized via an
AUTOSAR FlexRay stack. Compared to CAN, more than twice as many
measured values can be acquired simultaneously using XCP-onFlexRay. Furthermore, it is possible to transmit large quantities of
data with a higher throughput.
XCP on FlexRay
A laboratory model by itself is of limited use in determining the
parameters of a control algorithm. Although the algorithms of the
functions are permanently stored in the ECU-specific software
program, parameter values such as characteristic maps, curves and

values need to be recorded and optimized in measurements made
on the test bench and in driving trials. Audi engineers tune their
chassis and assistance systems in the framework of ECU calibration,
and they then load the parameter set files into the ECUs application memory.
To calibrate ECUs centrally from a single master and via a uniform
interface over the entire course of development a standardized
measurement and calibration protocol is necessary. In 2003, ASAM
(Association for Standardization of Automation and Measuring Systems) defined the universal measurement and calibration protocol,
XCP, to serve this purpose. It is a logical advancement of CCP (CAN
Calibration Protocol) [1]. Communication via XCP is executed by the
Master-Slave principle. An XCP software module integrated in each
ECU serves as a slave. The greatest advantage of the XCP protocol is
that it offers separation of the transport and protocol layers. The
protocol layer is the same on all bus systems, regardless of whether
4/4
09.02.2010 13:25:46 Uhr
Figure 1:
As the XCP-on-FlexRay master,
CANape measures and calibrates
individual nodes directly via
FlexRay
they are CAN, FlexRay, Ethernet or SPI/SCI. In February 2006, ASAM

officially released Version 1.0 of the Transport Layer specification
for XCP on FlexRay.
On earlier CAN projects, the Audi development team had already
worked with XCP and CANape, the all-round tool from Vector for ECU
measurement, calibration and diagnostics (Figure 1). CANape has
supported an XCP-on-FlexRay interface since 2005. Audi decided to
source both the XCP master (CANape) and the protocol and
transport layer software modules for the slaves using XCP-onFlexRay from a single supplier.
XCP integration in the AUTOSAR model

Audi integrated the XCP software modules in the ECUs of various
suppliers. Even after the ECUs calibration is over, the XCP software
modules shall remain available. This makes efficient memory
Figure 2:
Integration of
Vector XCP software modules in
an AUTOSAR 3.0
compatible
application.
4/5
09.02.2010 13:25:47 Uhr
utilization and minimal execution time essential. In addition, the

XCP software modules have to be AUTOSAR-compatible. Vector
implemented this requirement on the XCP transport layer such that
it is placed above the AUTOSAR communication stack (FlexRay or
CAN) using the PDU router (Figure 2). In the integration phase,
the two XCP software modules are configured with the help of the
GENy configuration tool and a network description file in FIBEX
format.
Dynamic management of FlexRay bandwidth

Since AUTOSAR compatibility is required for the XCP-on-FlexRay
software modules, this means that the PC-supported master must
perform special tasks. During ECU calibration, the XCP master and
slaves exchange FlexRay messages. These frames contain either
Command Transfer Objects (CTO) with control commands or Data
Transfer Objects (DTO) with measured or stimuli data. When such an
XCP object is transmitted to the master (Figure 3), the XCP transport layer transfers the data to the PDU router and thereby to the
FlexRay interface.
Because of the requirement for AUTOSAR compatibility, this
transfer must be made in the form of an AUTOSAR-conformant PDU
(Protocol Data Unit). Since the PDU originates from the XCP module, it is called the XCP-PDU. The FlexRay interface completes the
received XCP-PDU by adding its own specific information in the
form of a PCI header (Protocol Control Information), thereby forming an L-PDU (Data Link Layer PDU), which in turn is routed to the
FlexRay driver. That is how each participating software module
completes data received with module-specific information, making
it possible to reconstruct the data at the receiver. At the end of the
chain, the FlexRay controller transmits the XCP data as a frame
within a FlexRay slot (time window). Per the XCP specification these
frames must exclusively contain XCP data. Therefore, in the crosssystem FIBEX network description file, some slots in the FlexRay
schedule are exclusively to be reserved for XCP-PDUs and cannot
not be combined with PDUs issued from the application.
For the control commands (CTOs), two individual XCP slots are
sufficient for all ECUs thanks to the slave-referenced node address
(node address for XCP: NAX). The exact number of DTOs needed for
the measured data or stimuli data depends on the specific measurement being executed and may vary widely over the course of a
calibration. So the need for XCP slots also varies for each ECU.
To ensure that Audi engineers can efficiently transmit XCP data
from multiple ECUs with a limited number of available XCP slots, it
is necessary to dynamically allocate the available bandwidth at
runtime to all participating ECUs. However, AUTOSAR does not allow
reconfiguration of the FlexRay driver at runtime. Therefore, in
the integration phase the FlexRay drivers are configured so that
all XCP slots are allocated to all of the ECUs. At the same time, the
XCP-PDU/L-PDU/XCP slot allocation is set in each slave (Figure 3).
Figure 3:
XCP data are transmitted via various
software modules.
4/6
09.02.2010 13:25:47 Uhr
XCP-ON-FLEXRAY AT AUDI
As a result, at the end of the configuration process of an ECU, a

unique XCP slot in the FlexRay schedule is available for each individual XCP buffer. To attain the necessary flexibility over all ECUs,
the XCP transport layer command FLX_ASSIGN is used to modify
on the XCP level the allocation of XCP buffers to the different
L-PDUs (or FlexRay slots) before each measurement (Figure 4).
What is important here is to configure all participating ECUs with
the maximum available XCP slots, during software integration. This
results in the identical allocation of XCP slots on each ECU. Before
each measurement, only those XCP buffers that are actually needed
are selected. A central dynamic bandwidth management ensures
unique ECU slot allocations for XCP among all slaves. CANape handles this task with the help of the ECU-specific A2L description files
that provide information about the internal ECU buffers.
XCP use is optimized thanks to FlexRay
payload, offers XCP frames that are many times longer than those
of CAN (8 bytes). The Short Download function simultaneously
encodes the address and contents in a single L-PDU, so that memory areas can be exchanged between the master and slave much
more quickly than with CAN.
Furthermore, XCP enables oversampling, which is independent
of the FlexRay cycle, in order to measure very dynamic signals
(Figure 5). CANape uses the so-called In cycle multiple DAQ list
transmission to acquire measured signals of a predefined DAQ list
and their time stamps multiple times per FlexRay base cycle (generally 5 ms long).
To significantly accelerate the start procedure before each measurement, the necessary initialization also had to be optimized
thanks to the extension of the previous single WRITE-DAQ command. The new command WRITE-DAQ-MULTIPLE from the not yet
released XCP Protocol Layer 1.1 has been already used to configure
multiple signals by a single command.
The new dynamic bandwidth management is only one of the

FlexRay-specific CANape functions that support efficient ECU calibration at Audi. In three additional functions, Vector specifically
exploits the fact that FlexRay, with its up to 254 bytes of data
Figure 4:
Before each measurement, the XCP
objects are dynamically configured
in the dynamic segment.
4/7
09.02.2010 13:25:48 Uhr
Summary
Audi engineers rely on the MCD tool CANape to develop new models
in the context of test trials and calibration drives, in order to measure and calibrate internal ECU parameters with XCP-on-FlexRay.
Vector has extended its CANape and XCP software modules for this
purpose. Besides extending the XCP software modules for AUTOSAR
compatibility, a major task was to implement dynamic bandwidth
management for FlexRay. Choosing Vector as software supplier and
development partner was easy for Audi, since both the XCP software modules for the slaves and the XCP master, CANape, come
from a single source Vector and are perfectly tuned to one
another. All extensions can be obtained for the current version of
CANape and the XCP-on-FlexRay software modules.
Translation of a German publication in

Hanser Automotive, 7-8/2008
Christian Braun, Audi

studied Electrical Engineering at the Technical College of Munich, specializing in Data
Technology. After graduating in 1996, he
joined Audi AG where he was responsible for
electronic development of various ESP
systems. Since 2006, he has been working in
the area of Chassis Electronics Development
at Audi where he is responsible for measurement tools and system networking.
Pascale Morizur, Vector

studied Physics-Electronics at the Grande
cole ICPI in Lyon (France). After graduating
in 1986, she worked for 10 years at MAN
Commercial Vehicles in advanced development for the area of CAN, J1939 and Diagnostics. Since 2005, she has been employed as
a product management engineer at Vector
Informatik GmbH in the area of Embedded
Software Components.
Literature:
[1] www.asam.net
Links:
Homepage Audi AG: www.audi.com
Homepage Vector: www.vector.com
Product Information CANape: www.vector.com/canape
Product Information XCP on FlexRay: www.vector.com/canape_flexray
Figure 5:
The slave uses
Incycle multiple
DAQ list transmission to measure
very dynamic
signals from a DAQ
list. The signal is
measured several
times per FlexRay
base cycle.
4/8
09.02.2010 13:25:48 Uhr
4/9
09.02.2010 13:25:49 Uhr
XCP at the Focal Point of Measurement

and Calibration Applications
More and more electronic functions for safety and convenience are finding their way into the modern automobile. Since the
number of ECUs is being held in check, however, this means that the complexity of individual devices must grow to compensate. Making an important contribution toward rationalization of the development process for these distributed systems is
the XCP communication protocol, whose main tasks include measurement and calibration of ECU-internal variables at runtime. A tremendous advantage of this successor protocol to CCP is its independence of the physical transport layer.
Today, control modules with more than 10,000 parameters are no
longer uncommon. Since numerous dynamic processes need to be
controlled in a vehicle, the typical tasks of ECU calibration include
optimization of control algorithms.
In the case of a PID controller, there are almost limitless possible
variations in calibrating the proportional, integral and derivative
components. Therefore, it usually takes some effort until a sufficiently good compromise is found between stability, speed and
transient behavior. This can be accomplished by reading and modifying parameters during runtime (Figure 1).
To keep the time and cost requirements for ECU calibration low,
engineers and technicians depend on powerful tools and standards
that enable flexible read and write access to variables or memory
contents. For this purpose, the CAN Calibration Protocol (CCP) was
created in the 1990s, a time in which CAN was the only dominant
networking system in the automobile. CCP was slated to become a
cross-OEM standard. However, additional bus systems such as

FlexRay, LIN, MOST, etc. came into play with the continued development of automotive electronics. Since CCPs use was restricted to
CAN-networked applications, it increasingly encountered limitations in terms of its potential areas of use. This led to the development of its successor, XCP.
Universal standardized protocol

The Universal Measurement and Calibration Protocol (XCP), like
CCP, also has its origins in the Association for Standardization of
Automation and Measuring Systems (ASAM) [1] and was standardized in the year 2003. The X stands for the variable and interchangeable transport layer. XCP separates the protocol and transport layers completely by means of a two-layer protocol, and it
takes a Single-Master/Multi-Slave approach. Depending on the
4/10
09.02.2010 13:28:05 Uhr
transport layer in question, the protocol might be referred to as

XCP-on-CAN, XCP-on-Ethernet, XCP-on-UART/SPI or XCP-on-LIN, for
example (Figure 2).
A XCP Master is capable of communicating with different XCP Slaves
simultaneously. These include:
> ECUs or ECU prototypes
> Measurement and calibration hardware such as debugging
interfaces or memory emulators
> Rapid prototyping hardware
> HIL/SIL systems
identifies the amount of bandwidth still available and dynamically

allocates it to the current application data traffic very efficiently.
The available bandwidth is thereby optimally exploited in XCP communication and hardly affects normal FlexRay communication at all.
Other options being considered for the future include XCP-onLIN; also possible would be XCP-on-K-Line or XCP-on-MOST, if there
is sufficient demand for them from user groups. The broad range of
supported transport layers enables simple migration from broadband solutions such as Ethernet or USB in the development phase
to a final CAN interface in series production.
To meet the challenge of serving as a universal communication

solution for a large variety of applications, the ASAM Working
Group emphasized the following criteria in the design of XCP: Minimal resource usage in the ECU for RAM, ROM and required runtime,
efficient communication, easy implementation of the XCP Slave,
plug-and-play capability with low configuration effort, small number of parameters and scalability.
Single-Master/Multi-Slave concept
Interchangeable transport layer

XCP is capable of utilizing the same protocol layer on different
transport layers. This protocol is a universal measurement and calibration protocol that operates independent of the network type
used. Currently, ASAM has defined these transport layers in standards: XCP-on-CAN, XCP-on-SxI (SPI, SCI), XCP-on-Ethernet (TCP/IP
and UDP/IP), XCP-on-USB and XCP-on-FlexRay. The last named
variant is the latest member of the protocol line-up, and it has
been specified since early 2006. One special technical feature of
XCP-on-FlexRay is its dynamic bandwidth control. A measurement,
calibration and diagnostic tool (MCD tool) such as CANape [2]
The measurement and calibration system assumes the role of the

XCP Master, while the ECU acts as a Slave. Master and Slave each
communicate via the XCP drivers integrated in them. For each Slave
there is an ECU description file; information specified in this file
includes: Allocations between (symbolic) variable names and their
address ranges, physical meanings of the data, and the checksum
method being used. The XCP Master can read out all of the information it needs from these A2L description files.
In communication via XCP a distinction is made between the
Command Transfer Object (CTO) and the Data Transfer Object
(DTO). The Master might send a command via a Command Transfer
Object over the bus to the ECU that acknowledges it over the same
path after executing the requested service. CTOs provided are: CMD
(Command), RES (Response), ERR (Error), EV (Event) and SERV
(Service Request Processor). The DAQ (Data Acquisition) and STIM
(Stimulation) Data Transfer Objects are used for event-driven reading of measurement variables from memory, or for writing of values
to the memory of the XCP Slave (Figure 3).
Figure 1:
Optimization of a PID controller
algorithm with the measurement,
calibration and diagnostic tool
CANape.
4/11
09.02.2010 13:28:06 Uhr
From automotive bus to standard PC interface

PC platforms are used almost exclusively as the Master for measurement and calibration tasks. For direct connections to automotive
bus systems such as CAN, LIN, FlexRay, MOST or K-Line, the PC is
generally equipped with one or more hardware interfaces. Furthermore, the XCP Master is capable of utilizing standard PC interfaces
such as Ethernet, USB and RS232. Of course, in such solutions no
other costs are incurred for interface hardware. Measurement and
calibration systems with debugging interfaces (JTAG, TRACE, etc.)
and memory emulators can be implemented in this way. In principle, the standard PC interfaces are also well-suited for connecting
gateways between different bus systems; FlexRay-on-Ethernet
could handle this, for example. And finally, there are the conventional analog and digital I/O channels that are utilized in many
development and test layouts involving especially time-critical
measurements.
A significant advantage in the use of XCP lies in the fact that a
single standardized protocol suffices for all of these applications.
Without XCP it would be necessary to implement a proprietary driver for each communication channel. However, performance losses
need to be taken into account when multiple drivers are used in
parallel. Moreover, the risk of undesirable interactions and instabilities increases.
Versatile, scalable and resource-economizing

One and the same XCP driver code is used for all communication
processes. It can serve to send just a few bytes that come from
small controllers and interfaces, e.g. 8-Bit processors with integrated serial interface. Or the same code might be used to send
megabyte-size data volumes with 32-bit processors over highspeed networks such as Ethernet. Since an XCP driver is made up of
mandatory and optional functions, driver size can be scaled to
match the available ROM/Flash size. In the ECU, resource usage is
characterized by whether the focus is on high data throughput or
on low processor load and RAM size. With regard to bus load, the
basic consideration is: Number of signal transmissions vs. bus
bandwidth. Overall, the XCP drivers are easy to implement and
require just a few parameters.
Event-driven periodic data acquisition

ECUs operate in discrete time intervals. The length of such a time
interval can be defined in a fixed way (e.g. 10 milliseconds) or the
length of a time interval may be event-dependent (e.g. one engine
revolution). In the case of fixed defined time intervals, the end of
the time slice is marked by the expiration of a timer. Expressed in
generalized terms, such expiration of a timer is also an event. The
task of the ECU is to complete all computational and control tasks
within the specific time slice. To obtain correlated data from the
XCP Slave, the DAQ mechanism of the XCP protocol is now used. In
this mechanism, the XCP-Master informs the Slave, before the
beginning of the measurement, which signals are to be measured
when certain events elapse. If the event now occurs (e.g. the 10
millisecond timer expires), the XCP Slave reads the previously
defined data from the memory, copies them to a protected RAM
area and sends them to the Master in the form of messages. This
assures that the values originate from the same event cycle and
correlate.
The Master receives the data provided with a time stamp and saves
them to a measurement file. The time stamp is either sent out by the
Figure 2:
Separation of transport and protocol
layers lets XCP utilize a large
number of hardware interfaces.
4/12
09.02.2010 13:28:06 Uhr
XCP AT THE FOCAL POINT OF MEASUREMENT AND CALIBRATION APPLICATIONS
XCP Slave as a datum, or it is assigned to messages by the interface

hardware being used, e.g. CANcardXL. In the measurement file, all
data are synchronized in reference to the Master time base and are
then further processed, e.g. by visualizing the measurement values
on a global time axis. This allows multiple data channels of different
XCP Slaves to be displayed consistently in one diagram.
Besides the advantages of XCP compared to CCP already been
mentioned, XCP also offers support of so-called cold-start measurements and internal ECU time stamps for tasks in cyclic data
acquisition. In cold-start measurement the ECU can be configured
so that it begins to periodically send out data immediately after
being activated, i.e. the Master does not need to initiate this
explicitly. If an internal ECU time stamp is being used, it is not the
time of receipt that is relevant for later evaluation in the measurement and calibration system, rather it is the time at which the data
were created in the XCP Slave. This eliminates uncertainties attributable to possible delays in the transmission process, e.g. under
conditions of insufficient bus bandwidth or high load.
Optimizing characteristic curves and maps

Besides control algorithms based on mathematical models, ECUs
also utilize characteristic curves and maps composed of discrete
interpolation points. To achieve desired system behavior, such
characteristic value tables are usually set up and optimized experimentally, e.g. at the test bench. A2L files serve to describe the
measurement variables and calibration parameters. The description options in the A2L files range from simple scalar parameters to
complex tables. Among other things, the descriptions encompass
the data types, conversion rules between raw and physical values,
storage schemes for characteristic maps, and much more. Highperformance calibration tools such as CANape from the Vector display the characteristic curves and maps clearly on the screen in
graphic diagrams or as numeric values in tables.
Rapid prototyping with CANape and XCP

During ECU development important functions are frequently swapped
out to external simulation systems, so that they can be computed
with less effort. It is not until the algorithms in the simulation model
have reached a certain maturity level that the developer generates
from them a source code that is compiled together with other ECUrelevant codes and flashed in the ECU. However, even before this
occurs so-called bypassing, a coupling between a real ECU and its
model, is desirable so that tests and optimizations can be made independent of the hardware at an early point in development.
In bypassing with XCP, the Master reads data from the ECU by
DAQ, passes the values to the model as input values and sends the
models results back to the ECU by STIM. Noteworthy in this context
is that normal PC platforms running the MCD tool CANape are sufficient for bypassing and modeling. This is good news, since solutions based on special real-time hardware would be many times
more expensive and would only be available in limited numbers in
development departments. CANape, as a highly optimized XCP Master, simultaneously handles communication with the real ECU and
with the model running on the PC (Figure 4). The ECU parameters
and model parameters can both be calibrated via CANape and XCP.
Figure 3:
Communication between Master and
Slave.
CTO = Command Transfer Object
DTO = Data Transfer Object
4/13
09.02.2010 13:28:07 Uhr
Flashing via XCP

XCP also offers benefits to the user in programming ECUs. The data
in the ECUs flash memory are only reprogrammable using specially
prepared flash routines, which must also reside in the ECU. In principle, two approaches are conceivable: In solution 1, the flash routines are stored permanently in flash; first, this wastes memory,
and second, it presents a security issue for delivered vehicles. In
solution 2, a PC tool only loads a flash kernel to the microcontrollers RAM via XCP if it is needed for reprogramming. Besides containing the flash routines for erasing the flash memory and rewriting data, the flash kernel also contains its own bus and SCP drivers
for communicating with the PC tool over the bus interface.
Vector provides a free driver for setting up a XCP Slave that can
be downloaded at its web site [3]. The MCD tool CANape, in use as
an ECU calibration tool since 1996, is continuously updated as an
XCP Master to the latest level of XCP standardization based on
Vectors active participation in ASAM working committees. CANape
is the first tool on the market to have an XCP-on-FlexRay interface.
In the development of the first production vehicle with FlexRay,
the BMW X5, this was a crucial factor in the decision by BMW engineers to rely on Vectors XCP stack and CANape for calibrating the
damper control system.

Elektronik automotive, 4/2007
Summary
XCP is a standardized and universally applicable protocol with much
rationalization potential. It is not only used in ECU development,
calibration and programming; it is also used to integrate any
desired measurement equipment for prototype development, functional development with bypassing and at SIL and HIL test stands.
For quick access to internal data via microcontroller debugging
interfaces such as NEXUS, communication occurs over dedicated
hardware, trouble-free. This hardware converts communication
from NEXUS to XCP-on-Ethernet. The benefits to the user are independence from tool producers with proprietary solutions, and reusability of components.
Literature and Links:

[1] www.asam.net
[2] www.vector.com/canape
[3] www.vector.com/downloads/drivers/xcp.exe
Figure 4:
Bypassing: Use of a standard PC with
CANape as a test system.
4/14
09.02.2010 13:28:07 Uhr
XCP AT THE FOCAL POINT OF MEASUREMENT AND CALIBRATION APPLICATIONS
Andreas Patzer
After a practical education to become an IT
technician, Andreas Patzer studied Electrical
Engineering at the Technical University of
Karlsruhe between 1986 and 1993. He specialized in measurement and control engineering as well as information and automation engineering. After receiving his degree,
Mr. Patzer worked in the communications
industry. In 2003 he joined Vector Informatik
GmbH in Stuttgart where he handles the
interface between customers, development
and sales as Business Development Manager
for the Measurement and Calibration product line.
4/15
09.02.2010 13:28:07 Uhr
Quantum Leap in Microcontroller Measurement Technology

Innovative ECU measurement concept for maximum data rates with minimal effects
on execution time
In the development of complex ECU applications, there are greater and greater quantities of data to be processed, more
signals to be measured, and a growing number of parameters to be optimized. Previous methods for measuring, calibrating
and flashing are increasingly encountering limits with regard to the necessary data throughput. It was in this context that
Robert Bosch GmbH initiated a search for a more powerful and future-robust measurement concept for the next generation
of its ECUs, in particular for the development of a new long-range radar sensor.
The long-range radar sensor LRR3 (Long-Range Radar) from Bosch
operating at 77 GHz is the sensory input for many safety-related
and driver assistance systems. They include various versions of Predictive Safety Systems (PSS) and Adaptive Cruise Control (ACC).
These smallest radar sensors in automotive industry, used in production vehicles since the beginning of 2009, are distinguished by
their long acquisition range of 250 m and their wide aperture angle
of up to 45. Together with a favorable price the application area is
broadened from luxury class to mid-class vehicles and commercial
vehicles. This development posed enormous challenges for Bosch
engineers when it came to performing measurement and calibration tasks. Along with options for measuring and logging data, it
was essential to have efficient methods for calibrating and flashing
as well as bypassing. All of these applications require extremely
high transmission rates with low latency times.
From a technical perspective, it made sense to implement a modular layout of the measurement system and to make use of a standardized PC interface. Development of a near-production ECU
enabled a simple transition from development to production later
on. To acquire the large number of measurement signals, up to
100,000, without errors, a data rate of at least 4 MB/s is necessary
while affecting the processor as little as possible.
Existing solutions: Low data rates and high CPU load

In solutions that utilize the standardized measurement and calibration protocols [1] CCP or XCP-on-CAN, FlexRay, JTAG or SPI, a
driver integrated in the ECU is responsible for periodically reading,
copying and sending out the desired signal values. Due to the large
volume of data to be measured, the driver requires RAM memory
4/16
09.02.2010 13:26:12 Uhr
and processor resources that have limited availability. In addition,

there is increased loading of the data bus, which impacts the ECU
software in a negative way. Measurement data rates range from
50 KB/s for CAN up to maximum values of 400 KB/s for FlexRay,
JTAG and SPI (Table 1).
A high-performance debug interface on the microcontroller opens up new possibilities.

Bosch decided to join together with specialists at Vector to conceptualize an entirely new measurement and calibration system. As a
measurement interface it utilizes the Data Trace Interface, which
an increasing number of modern microprocessors are equipped
with for debugging purposes. More specifically, this is a standardized Nexus Class 3 Interface, which can communicate every change
in the ECUs memory to the outside world with minimal processor
load.
The fundamental idea of this approach is to acquire data from
the ECU via the debug interface and route it to an external measurement adapter via a special high-speed cable. The data are transmitted serially by a dedicated protocol. The external measurement
adapter is able to transmit the actual measurement data to the
application on the PC independent of the ECU via the standardized XCP-on-Ethernet protocol.
In the project, the interface on the ECU was implemented by a
Plug-on-Device (POD). This POD is especially compact, and it is easy
to mount it on the ECU. The POD contains all of the electronics
needed to acquire and send out measurement data. To assure errorfree operation, the POD fulfills the same mechanical and electronic
environmental requirements as the relevant ECU. This allows the
POD to be installed in critical locations in the engine compartment,
for example, which was a key requirement in the development project at Bosch.
Measurement adapter with mirror memory

A HSSL (High Speed Serial Link) cable up to 5 m in length connects
the POD to the VX1110 base module (measurement adapter) of the
modular VX1000 system developed by Vector (Figure 1). The base

module primarily consists of a FIFO buffer, Dual-Port RAM (DPRAM)
and XCP Engine that also has dedicated RAM. Write accesses to data
within the two user-definable memory areas are transferred to the
FIFO buffer in the base module via the HSSL connection and the
debug interface. The data are further processed and written to the
DPRAM there. From a logical perspective, since this data is identical
to the data stored in the ECU, the DPRAM always contains a current
mapping of the data, mirroring memory areas in the ECU. The crucial aspect of this approach is that all measurement processes occur
via the mirror memory. To initiate a measurement and thereby initiate data transfer, it is sufficient to have the ECU write an event
number to a predefined memory address that is allocated to the
measurement data. At precisely this time point, the connection
between the FIFO and DPRAM is disconnected, freezing the memory map at the trigger time. This keeps the data to be measured
constant over the measurement period. The XCP Engine now processes the data according to the protocol.
A transmission rate of up to 5 MB/s was achieved for the XCP-onEthernet connection between the VX1100 measurement adapter
Figure 1:
The VX1000 system is distinguished by very high measurement data rates and very low software modification
requirements and effects on ECU execution time.
ECU interface
ECU softwaremodification
ECU RAMreqmt.
Measurement
data rate
ECU execution
time effects
Bypass latency
time
CCP/XCP on CAN
CCP/XCP driver
software
12 KB
50 KB/s
Moderate
High
XCP on FlexRay
XCP driver software
216 KB
50400 KB/s
Large
Moderate
XCP on JTAG/SPI
Tables for DAQ transfer

via software
416 KB
200400 KB/s
Large
Moderate
Data trace VX1000
Low
None
5,000 KB/s
Very low
Low
Table 1: Comparison of different methods of measurement data acquisition
4/17
09.02.2010 13:26:13 Uhr
and the measurement and calibration tool on the PC. A highly

robust, temperature-resistant HSSL cable was used to ensure absolutely error-free data transmission in the engine compartment. In
case of transmission errors, a retransmission protocol provides for
quick repetition of data packets.
A look at the systems performance demonstrates that the effort
was very worthwhile. The VX1000 measurement system impresses
with a measurement data rate of up to 5 MB/s, it enables a write
rate of about 1 MB/s and handles the 100,000 signals of the Bosch
application effortlessly. The precision of the time stamps is 1
microsecond, while bypass turnaround times of 300 microseconds
were attained.
fulfilled all expectations set in the Bosch project. Last but not
least, along with good cooperation between the two companies,
the CANape tool for measurement, calibration and diagnostics
made an important contribution to successful project completion.
CANape is primarily used to optimally parameterize ECUs. In the
development and optimization of driver assistance systems like
ACC, the CANape Option Advanced Multimedia offers specialized
capabilities. Among other things, it lets users display objects
detected by the system in a perspective view in time-synchronously
logged video images, which gives them a reliable means for verifying object detection algorithms.
Other application options and outlook

From laboratory simulations to rapid prototyping
These properties make the system ideally suited for the two primary
applications at Bosch. The first application is bit-precise simulation
of real scenarios in the laboratory. This involved feeding certain
scenarios into the simulation without requiring real vehicle drives.
The second application, bypassing, is used to execute and test
functions outside of the ECU.
The described measurement system fulfills all requirements necessary for the LRR development, and it is now being used in other
projects at the Bosch company. Compared to classic measurement
principles, the VX1000 solution offers performance increases by a
factor of 10 to 100 in all disciplines. The effect of measurements on
the ECU, with CPU loading of less than 1%, lies significantly below
usual values. The modular layout of the VX1000 system assures
cost-effective re-use as a measurement technology solution in subsequent projects, even with different microcontrollers.
The right solution for any required measurement data

rate
The VX1000 system completes Vectors product line of measurement
and calibration tools at the top end of performance. Because it
could reach previously unattainable measurement data rates, it
The standardized XCP-on-Ethernet protocol can be used with both

the VX1000 product line and other measurement and calibration
tools. In the case of measurement and calibration tasks in the
engine compartment, the VX1000 is not really an off-the-shelf
product, since the harsh environmental conditions and limited
installation space generally require custom modification of the ECU
connection. In the framework of project work, Vector can work out
individual solutions in close dialog with its customers. Devices currently supported, besides the Freescale PowerPC, are the TMS570
from Texas Instruments and the Infineon TriCore processors with
DAP interface which are widely used in engine controllers
(Figure 2). DAP enables a cost-effective solution via a plug connector on the mini-PC-board connected to the ECU. Cycle times of
50 microseconds are possible with the measurement and calibration system. These requirements are relevant in the development of
vehicles with electric/hybrid drives, for example.
Based on acceptance of the VX1000 system among automotive
OEMs and suppliers, all sorts of extensions and new features will be
offered in the near future. They include plans to support additional
processors. Well-known semi-conductor manufacturers have
approached Vector seeking recommendations on how to adapt their
processor architectures in the direction of optimal measurement
functionality.
Figure 2:
High flexibility in
measurement and
calibration tasks
is achieved by
modular layout
with base module,
ECU interface,
cables and POD.
4/18
09.02.2010 13:26:13 Uhr
QUANTUM LEAP IN MICROCONTROLLER MEASUREMENT TECHNOLOGY
[1] XCP protocol: www.asam.net
[2] Presentations by Riedl, A. and Kless, A. at the Vector Congress 2008.
Download at www.vector.com/veco08
Andreas Riedl (Dipl.-Ing. (FH))

is Project Leader for engine controllers in the
international field at Robert Bosch GmbH.
E-mail: andreas.riedl@de.bosch.com
Alfred Kless (Dipl.-Ing. (FH)),

a Business Development Manager at Vector
Informatik GmbH since 2004, is responsible
for the Network Interfaces and Measurement and Calibration product lines.
E-mail: alfred.kless@vector.com
4/19
09.02.2010 13:26:14 Uhr
Efficient Analysis of Model Behavior in ECU Function

Development
The focus in ECU function development is always on finding the best possible control algorithms and parameter combinations. A new solution now offers users a single measurement and calibration tool with universal application from initial
model design to the production level ECU.
In the framework of model-based software development, application functions are checked in an iterative process. This involves
repeated runs of the model in Simulink from The Mathworks.
Depending on the results, the developer may add function blocks
by drag-and-drop operation from libraries. These blocks are
parameterized either directly in the function block with a numeric
value or by defining a parameter and its value on the MATLAB console. To modify an existing parameterization, the same steps are
executed again, either by looking for a block in the model and
changing its value, setting the parameter and its new value on the
MATLAB console, or modifying an M-script and running it. To visualize the signal responses that occur when the model runs in Simulink, the user instruments the model by attaching scope blocks to
each of the desired signals.
Use of the standardized XCP measurement and calibration protocol gives the developer a considerably more user-friendly way to
efficiently manage parameters and measure signals from the Simulink model without instrumentation.
4/20
09.02.2010 13:23:35 Uhr
Communication via XCP-on-Ethernet

The ASAM protocol XCP (Universal Measurement and Calibration Protocol) has become established as the preferred solution for measuring and calibrating applications in ECUs. This approach gives application engineers convenient access to measurement data and
parameters in the ECU via standard bus systems at runtime.
An ASAM standard A2L database (ECU description file) provides
all the information needed to access parameters and signals in the
ECU. It contains descriptions of relevant data objects within the
ECUs software, such as characteristic values (parameters, characteristic curves, maps) and measurement variables. The database
also connects the object names to their memory addresses in the
ECU and provides conversion rules for physical interpretation of the
raw data. Using such a database, measurement and calibration
tools can be used to acquire signal data or tune parameters as
desired by the user. Only a protocol driver is needed in the ECU; it
enables memory access at the ECUs runtime.
In the Simulink XCP Server option for the CANape measurement
and calibration tool from Vector Informatik GmbH, an XCP driver is
integrated into the Simulink model. As a result, the model is
treated like a virtual ECU. The effort required to integrate the XCP
driver is minimal: a single block from the Simulink CANape library
is dragged and dropped into the model. Settings of the XCP transport layer such as the host name and server port can be configured in the blocks dialog. They are necessary, since the XCP-onEthernet protocol is used to interconnect the measurement and
calibration tool with the Simulink model (Figure 1).
After this parameterization step, the XCP Server is ready to use.
The models A2L description file is generated from the blocks dialog. A virtual address is assigned to each Simulink object there.
This is how the Simulink XCP Server explicitly implements addressoriented XCP operation for the Simulink objects. The user then
selects objects in CANape in the usual way by their names. An
objects address is read-in from the A2L and is sent as information
to the XCP Server in the model. This means that for data objects in
the XCP Server, the address in the A2L file is only leveraged for
identification because the applications data objects do not yet

have a real ECU memory address. After instrumenting the model,
using it with CANape is easy and efficient because it is possible to
generate a CANape project directly from the configuration of the
blocks dialog in Simulink and start CANape with the created
project.
Numerous measurement and calibration functions

accelerate model optimization
The user visualizes the desired measurement parameters in the
measurement and calibration tool CANape independent of the
hierarchical organization and without further instrumentation of
the model. It is possible to display any of the input or output variables of the model blocks and have their time responses displayed
in graphic form. Parameters and signals can also be conveniently
displayed and calibrated right in the visualization of the model
(Figure 2). Simulink users will feel right at home in the familiar
model representation that does not require conversion. In the
model, a modified parameter is passed directly to the XCP Server
via XCP. It adjusts values in the Simulink blocks and in the base or
model workspace; this is equivalent to manually setting the values
via the MATLAB console.
The function developer can change parameters of a full Simulink
model, or those of one or more subsystems, easily and conveniently. This provides a way to test and optimize a Simulink model with
different parameter sets. CANape supports different file formats
here. Once the model has attained the desired maturity level, the
relevant parameters are saved to a parameter set file. The parameter set management feature of CANapes CDM Studio (Calibration
Data Management) is used to compare individual versions created
during model optimization and merge parameter subsets or work
packets to obtain optimal settings for the entire model. These settings may be exported in the form of a MATLAB M-script so that
they can be used directly as a new version level in the MATLAB/
Simulink development environment (Figure 3).
Figure 1:
Model objects can be measured and
calibrated conveniently and with
high performance using an XCP
Server integrated in the Simulink
model and an automatically generated A2L file.
4/21
09.02.2010 13:23:37 Uhr
MATLAB/Simulink as Time Master
Summary
Simulink models may run either slower or faster than real time,
depending on their complexity and computer performance. This
makes time stamps from Simulink indispensable. With each simulation step in Simulink, the associated time stamp is sent via XCP.
Consequently, variations in the amount of the time needed for the
simulation steps are irrelevant. Each simulation step corresponds
to one time unit, regardless of how much real time is needed for it.
In the process, Simulink acts as a time master, and the measured
data sent out by the model can be visualized in CANape at simulation speed. Depending on the complexity of the model, sensor data
from a one or two hour real test drive may be computed in just a
few seconds or in minutes. If a user wishes to simulate especially
large and complex models, standardized communication with XCPon-Ethernet enables better computing performance, since two separate computers are used.
The simulation results may be analyzed either manually or
through automation. In this process, an instance checks the
received results and makes a parameterization decision. Serving as
an instance is the CANape script language or an external software
program that CANape controls via one of the existing automation
interfaces.
Data from logged test drives may be fed into the model as an
input vector at runtime to stimulate the model with real data. The
function developer analyzes and optimizes system behavior under
comparable constraints. This eliminates the need for real, costintensive test hardware entirely.
The implemented access to MATLAB/Simulink models via XCP in a

measurement and calibration tool simplifies the work of function
developers considerably. For example, the model is automatically
instrumented via XCP, and this replaces the very tedious process of
manual instrumentation. As a universal front-end for measurement
and calibration tasks, CANape offers added convenience in the test
phase of models in Simulink. When XCP is used as a universal protocol over the entire development process, this reduces overall process complexity. The function development process is simplified
and accelerated, since just one protocol, one description file, and
one tool are used for all measurement, calibration, and stimulation
tasks.
Figure 2:
Efficient analysis of model behavior
by convenient navigation and quick
access to objects of the Simulink
model in CANape.
4/22
09.02.2010 13:23:37 Uhr
EFFICIENT ANALYSIS OF MODEL BEHAVIOR IN ECU FUNCTION DEVELOPMENT
Andr Ebner
is employed at Vector Informatik GmbH as Technical Team Leader for
the Measurement and Calibration product line.
Andreas Patzer
is employed at Vector Informatik GmbH as Business Development
Manager for the Measurement and Calibration product line.
Wojciech Przystas
is employed at Vector Informatik GmbH as a Software Development
Engineer for the Measurement and Calibration product line.
Figure 3:
Overview of actions in CANape and their effects on the
model in Simulink
4/23
09.02.2010 13:23:37 Uhr
Accelerated Turbocharger Development

Efficiently developing control concepts with a cost-effective rapid prototyping solution
Turbochargers help engines, especially those with comparatively small displacements, to develop considerable torque and a
high level of driving dynamics. Todays engine charging systems must flexibly adapt to engine speed and momentary power
requirements; therefore, turbocharger control requires careful optimization. For the automotive supplier BorgWarner Turbo
Systems, use of the CANape software tool has produced enormous streamlining potential in developing demo vehicles and
hardware equipment for road durability tests.
Charging of combustion engines is a core technology when it
comes to fulfilling requirements for low fuel consumption, low hazardous emissions and quality over long service life, while simultaneously improving driving dynamics. Today, 98% of diesel vehicles
are equipped with turbochargers in the passenger car area, and on
trucks approx. 80 %. With the introduction of direct injection, turbocharging is also being used more frequently to improve the efficiency of gasoline engines, although the considerably higher
exhaust temperatures make it essential to use higher grade materials that are more expensive.
Development competence and innovative force in demand

When a gasoline engine is driven at high power output, the turbine
can become white-hot at exhaust temperatures of up to 1050C.
Simultaneously, charger speeds typically reach 220,000 rpm, and
on smaller turbochargers, e.g. on the Smart car, they may even

reach 300,000 rpm. Accordingly, the challenges in the development of turbochargers lie in the areas of materials engineering,
cooling, bearings and high-precision manufacturing/balancing of
the rotating components.
The company BorgWarner Turbo Systems with headquarters in
Kirchheimbolanden, in the German state of Rheinland-Pfalz, is one
of the leading producers of turbochargers; it manufactures about
3.5 million charging systems annually in Germany and about 6 million worldwide. According to company information, BorgWarner in
Kirchheimbolanden currently has the most advanced development
center for turbochargers in the world. Besides various standard
products for diesel and gasoline engines, its product line also
includes advanced developments with multi-stage control of charging systems as well as the eBooster concept.
4/24
09.02.2010 13:24:51 Uhr
From the turbo hole to controlled charging

Due to its operating principle, high startup torque and high maximum power are mutually exclusive in simple turbocharger designs.
That is, either a compact system is constructed for high charge
pressure at low engine speeds or a large system optimized for high
speeds is constructed that neglects the desired dynamics in the
lower speed, which is then called a turbo hole.
Over the course of time, extended charging concepts have been
developed to overcome this handicap, e.g. the wastegate charger
equipped with bypass valve or the variable turbine geometry (VTG)
that has become a standard today. Its adjustable vanes can be flexibly adapted to the exhaust gas flow. The latest developments
include two-stage controlled charging with two charger systems in
series and the eBooster, in which an electrically driven flow compressor supports the turbocharger.
Turbochargers increase complexity of engine control

The more refined the designs for charge pressure control, the
greater the requirements for turbocharger control. In addition, it
was necessary to acquire turbocharger speeds, exhaust gas backpressures and underlying parameters such as angles or positions of
actuator elements by sensors and process them in the ECU. Actuators on the turbocharger consist of electrically or pneumatically
actuated components for adjusting the vanes or actuating flaps
and valves.
Control of the turbocharger is an integral component of engine
control, and it therefore falls under the area of responsibility of the
automotive OEM. In view of rising complexity, however, OEMs are
relying on the support of turbocharger producers in implementing
charge system control. In the development phase, BorgWarner uses
the Matlab/Simulink program package to design the relevant
control concepts that are provided to the customer for use on test
benches or in test vehicles.
Working efficiently on the visualized model

In calibrating prototypes in the engine or vehicle, Vectors CANape
measurement, calibration and diagnostic tool performs valuable service. CANape is a powerful ASAM-conformant tool for all tasks related to ECU calibration. Via physical interfaces such as CAN, FlexRay or
LIN and the standardized measurement and calibration protocols
CCP (CAN Calibration Protocol) and XCP (Universal Measurement and
Calibration Protocol), parameters can be measured from a PC at runtime, and they can also be calibrated at runtime. At BorgWarner the
capability of visualizing the Matlab/Simulink models in CANape is
particularly beneficial. Without requiring tedious searches through
documentation, the user can recognize directly from the visualized
model which parameters need to be adapted for the desired modifications. Search functions quickly lead to the desired parameters
and support convenient navigation through levels of the model.
In the production vehicle, the turbocharger application is run in
the engine controller. The sensor and actuator systems are also
connected here. During development, the turbocharger application
is swapped out to rapid prototyping hardware to enable flexible
testing of different software levels. This hardware consists of evaluation boards with integrated power electronics for driving the
actuators. This may involve use of an actuator/sensor combination
that differs from the one in the production vehicle (Figure 1).
CANapes tasks here include calibration of the engine controller
and the rapid prototyping hardware as well as visualization of the
Simulink model. This is precisely how CANape closes the gap
between the graphic representation of the model, which lets the
user visualize the interrelationships between variables, and the
A2L-based calibration of the application. The parameter files
Figure 1:
CANape is used to visualize the
Simulink model and serve as a
measurement and calibration tool
for the engine controller and rapid
prototyping hardware
4/25
09.02.2010 13:24:52 Uhr
created in optimization of the turbocharger application may of

course be exported from CANape and read back into Matlab/Simulink. Since this layout is well-suited to both test stands and test
vehicles, BorgWarner also implements it in road durability tests.
Outlook for the future

To achieve an even more efficient solution, BorgWarner is now testing CANape in conjunction with a PC as a rapid prototyping platform. In this case, the system makes use of a DLL generated from
the Simulink model, which runs in the CANape context. The Matlab
integration package supplied with CANape provides a CANape target with which the user generates CANape-specific code in the realtime workshop. The generation provides the DLL with an XCP interface, so that the user can access the DLL in measuring and calibrating as if it were running on a rapid prototyping platform
(Figure 2).
Together with the PC that is present anyways, CANape replaces
the prototyping hardware. If the XCP protocol is used in communication with the ECU, CANape can simultaneously be used as a
bypassing coordinator. The ECU data is measured in real time via
the tool, is passed to the compiled DLL model of the turbocharger
control system, is processed there and written back to the engine
controller ECU. The big advantage of this bypassing method is that
the DLL can be calibrated exactly like a real ECU. Parameter
changes take effect immediately, without requiring the detour of

making a modification in Simulink and then regenerating the code.
These applications point out the capabilities of high-performance development and diagnostic software in practice. CANape
makes part of the hardware equipment superfluous, saves on
licenses for modeling software and noticeably accelerates development progress due to fewer compiler runs. Calibration engineers at
BorgWarner benefit from visualization of the Simulink model,
including all of its key parameters. Even heightened real-time
requirements do not pose any problem here, since bypassing cycle
times as short as 2 ms are possible on PC platforms.

Hanser Automotive, 11/2007
Links:
Homepage BorgWarner Inc.: www.borgwarner.com
Product Information CANape: www.vector.com/canape
Figure 2:
PC and CANape used as rapid prototyping environment with supplemental
bypassing capability.
4/26
09.02.2010 13:24:52 Uhr
ACCELERATED TURBOCHARGER DEVELOPMENT
Gerd Spinner, BorgWarner Turbo Systems

is employed in the Product Development area
at BorgWarner Turbo Systems Engineering
GmbH.
Andreas Patzer, Vector Informatik

is employed at Vector Informatik GmbH as
Business Development Manager for the
Measurement and Calibration product line.
4/27
09.02.2010 13:24:53 Uhr
Optimizing Driver Assistance Systems

Verification of Object Recognition Algorithms by Driver Assistance Systems
Driver assistance systems address the issue of growing traffic volume by offering significant relief to drivers. To obtain an
objective assessment of control algorithms in the development of such systems, BMW is relying on the support of the
CANape measurement and calibration tool. Many suggestions by Munichs leading car producer also flowed into the design
of an extension that effectively handles the special requirements involved in calibrating driver assistance systems.
ACC (Adaptive Cruise Control) systems monitor the corridor in front
of a vehicle, detecting vehicles ahead and maintaining the distance
to these vehicles desired by the driver. ACC systems also adjust the
cars current speed to the traffic situation by automatically reducing engine torque, braking, and accelerating again, if necessary. To
maintain the correct distance to the vehicle ahead at any speed,
ACC systems require very complex and precise computing algorithms.
What sounds relatively simple is in reality a great challenge for
the development engineers, because a driving situation that a
human driver is able to evaluate effortlessly is a nearly endless
array of numbers in an ACC ECU. A forward-looking radar unit supplies coordinates of objects in cartesian form, i.e. in the X direction
(cars longitudinal axis) and Y direction (cars transverse axis), or
as polar coordinates with vehicle distance and azimuth angle. From
these, the ACC ECU concludes whether the distance to the car ahead
is sufficient, whether braking needs to be initiated or whether it is
possible to accelerate.
The evaluation electronics must also decide whether the acquired

object should even be considered as a relevant control object,
because the aperture angle of the radar sensors also detects any
objects adjacent to the roadway. While radar scanning initially
finds many objects, only the data of vehicles in ones own lane may
be utilized for adaptive distance control.
This is not a trivial task, since information from the radar sensor
system is not always clear and unambiguous. Some of the radar
reflections are bumps in the road or simply false reports. This indicates just how important it is to conduct a check of the acquired
data (signals) based on visible evidence (the video image). The
reliability and operating safety of this system, with its acceleration
and braking maneuvers, is in the truest sense a matter of life or
death. Faulty behavior could lead to vehicle reactions that are
incomprehensible to the driver.
For this reason, additional data are utilized at BMW to determine
the exact distance between vehicles and exclude irrelevant objects.
4/28
09.02.2010 13:28:19 Uhr
Besides dynamic driving data, data from GPS navigation are also
used, for example.
Since there were no suitable products on the market, BMW initially supported the ACC development process by a tool it had written in-house, which helped engineers reach an objective assessment of the control algorithms. For production development, however, BMW is now increasingly relying on standard products that
can also be used by its suppliers.
Tool-supported evaluation of sensor data and driving

impressions
Ever since the CANape Option Advanced Multimedia (AM) became
available, BMW has been using this tool more intensively on projects and in production development. The tools standardized calibration protocols and flexible interfaces enable simple integration
into an existing tool environment, leave room for engineering
extensions and offer maximum future compatibility, e.g. for obtaining objective test results to evaluate the assistance systems of
suppliers.
Even the base version of the measurement, calibration and diagnostic tool CANape from Vector is able to record all ECU-internal
data time synchronously (Figure 1):
> Signals from CAN, LIN and FlexRay bus with the CCP/XCP calibration protocols
> Peripheral measurement technology
> Video and audio signals, and
> GPS signals (optional).
To achieve optimal control functionality in the ECU, it is necessary

to make numerous parameter modifications in an iterative process
that can be performed online or offline with CANape. BMW utilizes
the CANape Option Advanced Multimedia, an extension especially
designed for developing driver assistance systems. A core element
here is the Multimedia Engine, which displays ECU signals and
information computed from them in 3D perspective in the video
display. The relevant ACC coordinates can then be placed over the
video image as defined bitmap information in 3D perspective (Figure 2). Only by means of such visual matching is it possible to
objectively assess the original mass of numbers. The BMW developers no longer just get coordinate information on the positions of
objects ahead of the driver; they can also immediately observe and
verify them in a video image from a birds eye perspective or side
view. Thanks to the saved information, it is possible to study real
driving situations which are normally never one-hundred percent
reproducible in the laboratory and efficiently adapt the control
algorithms.
Environment detection with the camera

A coordinate transformation is necessary to represent object data
from the ECU as geometric objects in the Video Window. To calibrate the connected camera, all the BMW developers need to do is
click eight reference points whose coordinates are known. Based on
stored information, the tool automatically computes a coordinate
transformation for each detected object from global coordinates
to image coordinates and then displays the objects accordingly in
the video image.
Figure 1:
Time-synchronous real-time acquisition and visualization of internal
ECU signals via CCP/XCP, and of signals from CAN, LIN and FlexRay buses and external measurement
equipment via CANape.
4/29
09.02.2010 13:28:20 Uhr
Vector also offers a suitable camera for the system, since BMW is
not the only customer who values a universal and tested solution.
ECU developers using CANape AM can use practically any desired
camera, from a webcam to a professional high-tech device, provided that it has a USB or Firewire port and a DirectX interface.
Optimal results are obtained with a camera that has a logarithmic
characteristic and 120 dB dynamic range that further enhances
image quality both in tunnels and in direct sunlight. It is also
possible to connect analog cameras via a Frame Grabber interface.
Depending on the camera resolution, image refresh rate and number of cameras used, data might accumulate at rates of 20MByte/
sec or more. That is why developers work with reduced image resolution; data compression units are also used to reduce the data
volume.
A number of standard pixel graphics are provided for object representation in the video image. For example, a detected vehicle
is represented by a rectangular frame, and other objects might
be shown as an X or a line. In the process, it does not matter
whether the ACC information is obtained from radar, infrared or
ultrasonic sensors. It is also easy to assign signals to an object with
the user-friendly GFX Editor for graphics (Figure 3). In another
dialog of the GFX Editor, the user defines the type of visualization
for the specific object type. This involves defining any objects
desired and linking them to the desired graphic symbols. In addition, users can also integrate their own graphics.
Joint advanced development work

For BMW, cooperative teamwork with the tool producer is a prerequisite for developing intelligent high-end systems. In this project,
good cooperation has led to ideas that have spawned real funct-
ional extensions. For example, today at the request of BMW

developers a so-called driving tube is generated with data from
the ACC ECU; it is then represented in the video image as either a
birds eye view or a 3D perspective. This driving tube corresponds
to a virtual driving lane that demarcates the presumed future path.
This defines the corridor ahead of the vehicle that is relevant for
distance computation. Objects detected by the ACC system lying
outside the driving tube do not need to be considered in distance
control, and they are therefore represented by a different frame
color. Also part of the evaluation is highlighting traffic signs and
traffic lights. Theoretically, the tool can be used to represent up to
50 different objects simultaneously.
Similarly high requirements are placed on the hardware. The
volume of accumulating data and enormous computational
demands on the computing platform are still a great challenge.
Previously, two PCs were needed to assure the specified performance. But this required manual data synchronization, since only
one of the computers could access the internal ECU signals. Today,
a dual-core computer platform is used for the ACC computations.
Since parallel recording of multiple video sequences and processing
of FlexRay data place increased demands on the CPU, BMW experts
are seeking more balanced utilization of the two computing cores.
Outlook
By visually comparing those objects detected by the ECU with the
real environment, BMW developers now have an easy and efficient
way to verify the object recognition algorithms of their ACC ECU.
Cooperation between BMW and Vector is bearing further fruit, e.g.
improved processor loading of dual-core and quad-core computing
platforms in future CANape versions and functional extensions for
Figure 2:
Objective evaluation of sensor data
and subjective impressions during
driving trials: object display from
birds eye perspective and overlay
on video image in the Multimedia
Window
4/30
09.02.2010 13:28:20 Uhr
OPTIMIZING DRIVER ASSISTANCE SYSTEMS
developing parking assistance systems. In the next few years, safety systems will also be implemented based on environmental data
acquisition. They require even higher levels of computing performance due to the need for comprehensive detection of the surroundings and networking of active safety systems to Adaptive
Cruise Control sensors. CANape AM will also let BMW developers
focus entirely on their core tasks in the future: considerable
increases in driving convenience and further safety improvements
in highway transportation.
Lorenz Eisenknappl,
Vehicle Dynamics Development: Team Leader for Control System
Measurement Technology, BMW AG
Walter Kagerer,
Vehicle Dynamics Development, Driver Assistance and Active Safety,
ACCSnG, ACC and DCC Calibration, BMW AG
Harald Koppe,
Vehicle Dynamics Development: Measurement Technology for
In-Vehicle Control Systems, BMW AG
Martin Lamprecht,
Vehicle Dynamics Development: Measurement Technology for
In-Vehicle Control Systems, BMW AG
Alexander Meske,
Vehicle Dynamics Development: Driver Assistance and Active Safety,
ACCSnG, ACC and DCC Calibration, BMW AG
Alfred Kless
is Business Development Manager for the Measurement & Calibration product line at Vector Informatik GmbH.
Figure 3:
Use of the GFX Editor for convenient
object-signal mapping and
grouping in displaying objects
4/31
09.02.2010 13:28:20 Uhr
09.02.2010
13:11 Uhr
Seite 1
Trends in Embedded Development

Requirements and future concepts
in hardware, software and tools
In the future continual advances in the development of automotive electronics will place signif icant new demands on underlying
base technologies. In spite of growing functionality automotive OEMs must keep costs
under control; one way to achieve this is by
limiting the number of ECUs in a car. At the
same time extended safety and reliability
concepts will be key areas of interest. In light
of the challenges and multitude of electronic components, power ful tools for development, data management and transfer of software modules into a control modules flash
memory will continue to gain in impor tance.
Without fur ther advances in standardization it no longer be
possible to master the growing complexity of automotive
electronics. In the 1990s automotive OEMs such as DaimlerChrysler went to great ef forts to establish the OSEK embedded operating system as a binding standard for in-house developments and supplier components. Today the real-time
and multitasking capable operating system is used by automotive OEMs and suppliers as the basis for improved code
quality, good structur ing and integration of the components
of dif ferent suppliers. In Hersteller Initiative Software
(HIS) too the large automotive OEMs have come to an
agreement on uniform standards. Working committees have
also been established in the areas of software, software
testing, process assessment, simulation and tools as well as
flash programming. The AUTOSAR (Automotive Open System
Architecture) Consor tium is responsible for the standards of
future vehicle generations.
[1]
[2]
OSEK: Flexible and calculable

A number of OEMs have cer tified OSEK implementations. Applications of the osCAN OSEK implementation, for example, range from normal ECUs to multi-bus gateways and inter face hardware. In the Vector Inter face for MOST VN2600
the per formance capabilities of osCAN were put to the test
under a 133 MHz Altera Excalibur controller processing up to
35,000 Events/s, which corresponds to a data throughput of
1.7 MByte/s. At gateway producer K2L osCAN-based solutions have demonstrated fast reaction times and precise timing.
5/0
An ECU for multiple applications

A clear trend in automotive networking is reduction in the
number of ECUs in a vehicle. Today up to 40 ECUs operate in a
luxury automobile. To permit implementation of even more
functions, in the future consistent ef forts must be made toward running as many applications as possible within the
same control module. The OSEK multitasking operating system was specified for this purpose. However, other proper ties are required of the operating system for use in safetycritical systems and to integrate the software of dif ferent
producers. For example, an application must not disturb other applications running in parallel.
Always in demand: The right timing

One of the focal points in advanced development of embedded operating systems, for future OSEK versions and
AUTOSAR, is the ability to monitor software behavior relating
to timing and memory accesses. The most advanced methods
for monitor ing timing are provided by AUTOSAR-conformant
implementations. Methods such as Execution Time Enforcement and Arrival Rate Enforcement provide a mandatory
minimum time budget for low-prior ity tasks too; these
methods not only detect errors, they can also clearly identify
their sources.
Reliable boundaries for memory protection

In the future memory protection functions will restrict a
tasks access to the memory space assigned to it. This is especially impor tant to prevent write accesses to other data
segments, detect stack overruns, and prohibit execution of
incorrect code. On the other hand, tasks belonging to the

same application need to be able to access the same memory
areas, and special system functions such as drivers could require unrestricted memory access. A distinction is made here
between so-called Trusted Applications with full access
rights and Non-Trusted Applications with restricted access
rights. These names can lead to some confusion: Non-trusted Applications are stored programs that cannot really cause
any damage.
It is good design practice to place functionalities in Non-Trusted Applications whenever possible. Vector Informatik
therefore of fers implementations that also permit calling of
Non-Trusted Functions. They are intended for safety-critical
09.02.2010
13:11 Uhr
Seite 2
applications and of fer a maximum level of reliability. A related proposal for handling this issue in AUTOSAR is currently
being discussed in a working subcommittee.
Better hardware support in the future?

The cited timing and memory monitor ing functions can only
be implemented ef ficiently with suitable hardware support.
What are needed for memory protection are Memory Protection Units (MPUs) that are tailored to the needs of automotive applications in terms of options of fered for number and
sizes of memory blocks. In many cases today the smallest
units that can be managed are blocks 16 kByte in size. In the
automotive embedded field, however, substantially smaller
memory units are needed.
Figure 2: osCAN TimingAnalyzer enables simulation of scheduling tables (schedules) and computation of sched ulability
5/1
09.02.2010
Essentially the hardware requirements of current and future

OSEK real-time systems can only be fulfilled by a complete
redesign of todays processor cores. Desired features are currently being negotiated with semiconductor producers.
Among the most impor tant requirements, besides the named
monitor ing functions, are an Interrupt Controller for dif ferent interrupt levels with low latency times, hardware support
in task switching, and processor cores with as few registers
as possible.
Can error-free embedded systems be developed?

Interesting possibilities for master ing industrial complexity
are being researched in ongoing projects involving the intensive application of mathematics to the engineer ing sciences. Systematic analytical methods enable detection of errors in real-time systems that would other wise not even be
revealed in extensive testing. Scientists on the Ver isoft project have taken this one step fur ther in concluding that it is
possible to develop error-free embedded systems and electronic components. Entire systems consisting of hardware,
software, operating system communication, applications,
etc., might be universally ver ified by methods of formal ver ification.
13:11 Uhr
Seite 3
from Vector Informatik save the flash data together with references to the flash jobs in a ODX flash data container.
In some cases it may be necessary to enable modification of
flash data in the field by means of a post-build process. In
this context it is impor tant to recalculate checksums and
signatures, in addition to other parameters, and to send
them to the flash bootloader dur ing a flash update. The
CANape Graph and CANdito tools, both online and off line
post-build processes can be handled in an elegant way, whereby a script language optimized for flash and diagnostic
tasks is very helpful.
Managing dif ferent memories in the ECU

An impor tant topic in reprogramming is the management of
dif ferent memory types in an ECU. Rising complexity, e.g. in
multiprocessor or distributed systems, goes hand in hand
with greater memory requirements and the use of dif ferent
types of memory. Some conventional nonvolatile memory
devices have very dif ferent physical character istics. Among
the impor tant dif ferentiating character istics of nonvolatile
Reprogramming ECUs
Reprogramming of ECUs by flexible flash programming is
continuing to draw greater interest. The issues here do not
relate to the actual flash programming technology as much
as they do to the organization and handling of the overall
process. Constraints vary from project to project, whereby in
addition to OEM and model specif ic requirements, other requirements must be considered such as hardware proper ties
(bootloader, flash initiation), flash formats, transport and
diagnostic protocols. If flash data pass through var ious
gateways, for example, it must be assured that no data can
be lost there. These and similar questions must be answered
individually for each par ticular situation. In practice it is not
really possible to implement a simple automatic approach
here. Given these constraints, the rational handling of flash
processes continues to gain in impor tance. Therefore, one
trend leads in the direction of uniform management of flash
processes in standardized formats. For this purpose, tools
5/2
Figure 4: Flash programming
09.02.2010
13:11 Uhr
Seite 4
TRENDS IN EMBEDDED DEVELOPMENT
memory types are: Size of the write segment, size of the erase segment, maximum number of programming cycles, and
times required to program and erase.
The latest flash memory is based on NOR Stacked Gate and
MONOS (Metal Oxide Nitride Oxide Silicon) technologies. Beginning about 2008 new memory products are expected that
are based on FeRAM (ferro-electric), MRAM (magneto-resistive) and other technologies, which could permit unlimited
numbers of write/erase cycles.
HIS-standardized Memory Driver Inter face

With the goal of achieving uniform memory management,
the HIS Automotive Group defined a standard for the Memory Driver Inter face that is experiencing growing support
from semiconductor producers. The inter face provides functions for initializing, de-initializing, erasing, programming
and reading data. In an implementation based on the HIS inter face a Multiple Memory Type I/O Manager used to access
var ious types of memory. The memory configuration can be
defined conveniently with the Geny tool from Vector. The user benefits from maximum flexibility in accessing dif ferent
memory types, including access by SPI (Serial Peripheral Inter face).
Time is money: Accelerating flash processes

Depending on the number of ECUs, it may take a full hour or
more to transfer data in the production environment. Therefore automotive OEMs and tool suppliers are consider ing
adding greater bandwidth to the transport media as well as
data compression. Scientif ic studies indicate that for compression purposes a combination of the LZ77 method and an
arithmetic coding method would be ideal and might reduce
data volume by up to one half.
[1] OSEK stands for Of fene Systeme und deren Schnittstellen fr die Elektronik im Kraftfahrzeug (Open Systems and their Inter faces for Electronics in Motor Vehicles).
[2] Hersteller = Producer or OEM
Author:
Peter Liebscher (Graduate Engineer) studied
telecommunications engineer ing at the
Technical College in Esslingen, Germany.
Since 2002 he has been employed as Business
Development Manager at Vector Informatik
GmbH where he is responsible for the Embedded Software Components product line.
Tel. +49-711/80670-413,
Fax +49-711/80670-111,
E-mail: peter.liebscher@vector-informatik.de
5/3
09.02.2010
13:06 Uhr
Seite 1
DEVELOPMENT TOOLS
Timing, memory protection and error

detection in OSEK systems
by Peter Liebscher, Vector Informatik
A powerful certified
OSEK implementation or
AUTOSAR-conformant
embedded operating
system, together with
a universal tool-chain,
will make it possible to
master the complexity
of future electronic
development.
Figure 1. Representation of
gateway, system and bus APIs
The real-time and multitasking operating system OSEK is the standard in automotive embedded developments today. Its most important
properties include low consumption of processor resources and memory, and event-driven
task management that effectively handles both
cyclic and non-cyclic program blocks. Continuing advances in automotive electronics and
the new HIS and AUTOSAR standardization
initiatives also place new demands on the
operating system. Areas of emphasis in future
operating system versions will be timing and
memory protection.
In the 1990s the large automotive OEMs introduced the OSEK/VDX operating system specification with the goal of establishing a uniform
standard for software in electronic control
units. The wide variety of proprietary embedded operating systems at numerous suppliers
had proved to be an obstacle to smooth integration in light of the growing significance of
automotive electronics. Besides defining the
actual operating system core, OSEK also defines
communication services and functions for
network management.
Since most automotive suppliers had already
committed to a preferred operating system beforehand, automotive OEMs had to introduce
OSEK persuasively in some cases. DaimlerChrysler, for example, made OSEK mandatory
as a standard for new developments, both for

in-house developments and those at suppliers.
The company organized OSEK training courses, created OSEK design guides and supported
operating system producers. It also financed
one OSEK licence per supplier, whereby only
certified OSEK operating systems were permitted. The costs of introduction reached a high
point in 2002 and then dropped significantly. In
the meantime OSEK has generated its own success, and now most ECUs in the automotive
field run on OSEK operating systems.
Efforts have paid off: applications based on
OSEK have fulfilled expectations by their improved code quality, structuring and the ability to integrate components from different suppliers. At gateway producer K2L solutions with
osCAN, the OSEK/VDX-conformant operating
system from Vector Informatik, have demonstrated fast reaction times and precise timing.
Last but not least, what has proven to be decisive for OSEK in conjunction with a table-driven interpreter concept are flexibility gains
leading to shorter development times, higher
quality and functionality and ease in creating
variants. Leading the way here were comparisons between OSEK with its preemptive
scheduling and a fixed coded static approach
with cooperative scheduling. The osCAN
OSEK implementation has proven itself, not
only in ECUs but also in the interface hardware
41
5/4
of the same company. In the MOST Interface

VN2600 osCANs capabilities were put to the
test under a 133 MHz Altera Excalibur controller: its processing of up to 35,000 Events/s
corresponds to a data throughput of 1.7 MB/s.
Requirements of an operating system grow in
parallel with the continuing penetration of electronic technologies. In particular the advance of
safety-relevant applications in the vehicle, such
as fully electronically controlled steering and
braking systems (X-by-wire), make deterministic behaviour essential under peak loads and
fault conditions. For example, the specification
of OSEKtime will supplement the event-driven OSEK with a time-triggered variant.
Fault tolerance, error detection mechanisms
and memory protection also play an important
role in achieving system reliability. This has acquired special relevance, because in the future
an ECU will handle multiple applications running simultaneously. In Hersteller Initiative
Software (HIS; Hersteller = producer or OEM)
the large German automotive OEMs have
come to an agreement on the standards needed to implement the named functions. Working
committees have been established in the areas
of software, software testing, process assessment, simulation and tools as well as flash programming. The AUTOSAR (automotive open
system architecture) consortium is responsible
June 2006
09.02.2010
13:06 Uhr
Seite 2
DEVELOPMENT TOOLS
properties are required of the operating system
for use in safety-critical systems and to integrate
the software of different producers. For example, an application must not disturb other applications running in parallel. To prevent this
from happening, new operating system features
are aimed at optimal monitoring of the time
behaviour of individual tasks and universal
memory protection.
Figure 2. Function block diagram with MOST interface VN2600 and an Altera Excalibur controller
Figure 3. Deadline monitoring to detect deadline violations. The error source of Task 2 is not found
in Task 1.
Figure 4. Tasks belonging to the same application must be able to access the same memory areas.
for the latest standards for future vehicle generations, whereby the HIS group is integrating
its results into AUTOSAR and is representing
uniformity interests there. When one considers
that over 50 ECUs operate on a luxury automobile today and that there appears to be no end
to potential new automotive electronic applicaJune 2006
tions in the foreseeable future, it becomes

clear why limiting the number of control modules in the vehicle has become a pressing topic.
This objective can only be achieved if multiple
applications run on the same control module.
The multitasking OSEK operating system was
specified for this purpose. However, other
Progress has varied considerably in the various

development levels as a result of these efforts.
OSEKtime, specified since 2001 for time-triggered tasks, with its deadline monitoring, only
begins to cover functions that will be necessary
in the future. Deadline monitoring detects
whether a task has ended by a prescribed
point in time. Unfortunately, the method cannot discern the causes for deadline violations.
For example, if the monitored task was interrupted by a higher-priority task, then the
monitored task is not really responsible for
being unable to satisfy the prescribed time window. In HIS-conformant OSEK extensions
memory protective functions are defined in addition to deadline monitoring. The most advanced is AUTOSAR with its execution time
enforcement and arrival rate enforcement
methods, which give low-priority tasks a
mandatory minimum time budget, too. These
methods are able to clearly identify error
sources. Furthermore, in the various operating
system versions, Vector Informatik has integrated options for run-time measurements.
Memory protection functions restrict a tasks
access to the memory space assigned to it. This
applies especially to preventing write accesses to
other data segments, detecting stack overruns,
and detecting execution of incorrect code.
Tasks belonging to the same application, on the
other hand, must be able to jointly access the
same memory areas. However, special system
functions such as drivers could require full unrestricted memory access.
A distinction is made here between so-called
trusted applications with full access rights and
non-trusted applications with restricted access rights. These names can lead to some confusion: non-trusted applications are programs
that, due to restricted memory access, cannot
cause any damage. The trusted applications, on
the other hand, are given quasi blind trust. The
latter are easy to use but represent risks to system security and cannot provide identification
of errors or error sources. It is good design
practice to place functionalities in non-trusted
applications whenever possible. Vector Informatik therefore offers implementations that
also permit calling of non-trusted functions.
They are intended for safety-critical applications and offer a maximum level of monitoring.
A related proposal for handling this issue in
42
5/5
09.02.2010
13:06 Uhr
Seite 3
DEVELOPMENT TOOLS
AUTOSAR is currently being discussed in a
working sub-committee. The cited timing and
memory monitoring functions can only be implemented efficiently with suitable hardware
support. What are needed for memory protection are memory protection units (MPUs)
that are tailored to the needs of automotive applications in terms of options offered for number and sizes of memory blocks. In many
cases today the smallest units that can be
managed are blocks 16 KB in size. In the automotive embedded field, however, substantially
smaller memory units are needed. Essentially,
the hardware requirements of current and future OSEK real-time systems can only be fulfilled by a complete redesign of todays processor cores. Desired features are currently being
designed together with semiconductor producers. Among the most important requirements,
besides the named monitoring functions, are an
interrupt controller for different interrupt levels with low latency times, hardware support in
task switching, and processor cores with as few
registers as possible. For hardware-related and
time-critical automotive applications what
counts is the ability to react as quickly as pos-
sible. Many of these applications consist of

drivers and interrupt service routines (ISRs)
which in contrast to the workstation field
belong to the application here. It is problematic that on todays controllers the ISRs often can
only be disabled completely. In general,
disabling mechanisms must be made more
efficient in implementations, since this basic
Interested in more information?

Visit our specific website with links to:
Real-time operating system for automotive
control units
Protocols and drivers for CAN
communication
Flash programming via CAN and LIN
Solutions for AUTOSAR by Vector
Simply type-in Reader Service #: 783 at
Embedded-Control-Europe.com/know-how
Figure 5. Phases of a task switch
5/6
09.02.2010
13:06 Uhr
Seite 4
DEVELOPMENT TOOLS
function is executed very frequently. The quick
task switches by which real-time embedded systems thrive are currently given just rudimentary support in hardware. The majority of resources is consumed in saving and restoring the
context. The context is made up of core registers, register banks, memory access registers,
floating point and arithmetic registers of the
stack pointers, special peripheral units and a
number of operating system variables. A fully
hardware-supported context switch would be
ideal here.
Furthermore, it has been shown that processors
with a low number of registers offer better performance. Many registers can only be used
meaningfully in typical workstation environments, because that is where individual program sequences run for a relatively long time
without interruption. A potential trend here
could lead in the direction of so-called softcore
processors and to compilers that permit configuration of the registers used. Interesting possibilities for mastering industrial complexity
are being researched in ongoing projects involving the intensive application of mathematics to the engineering sciences. Systematic analytical methods can be used to reveal critical
situations in the time behaviour of an OSEK
system that would otherwise not be found even
by extensive testing. In this context, tools
from the SympTAVision company enable targeted searches for bottlenecks and hot
spots, informing users of worst-case situations.
The advantages of systematic analysis lie in
June 2006
reduced testing effort, productivity gains,

quality improvement and comprehensive system optimization. Scientists on the Verisoft
project have taken this one step further in concluding that it is possible to develop absolutely error-free embedded systems and electronic components. They turn to the methods of
formal verification to verify entire systems consisting of hardware, software, operating system
communication, applications, etc. In cooperation with project partner Infineon, the TriCore
2 processor, the future flagship of the companys 32-bit microcontroller device line, offered
the first evidence that this innovative technology could be applied to highly complex designs. The long-term Verisoft project set up
under the project leadership of Prof. Dr. Wolfgang J. Paul, of the University of Saarbrcken,
is being supported by the German Federal
Ministry for Education and Research.
Foundations and base technologies have been
created for achieving reliable electronic systems
in the automobile. Specific challenges must still
be overcome by controller producers. Apart
from that it is the responsibility of automotive
OEMs and suppliers to utilize the available
resources optimally. A powerful certified OSEK
implementation or AUTOSAR-conformant
embedded operating system, together with a
universal tool-chain, will make it possible to
rationally master the complexity of future
electronic development. I
44
5/7
09.02.2010
13:05 Uhr
Seite 1
Current Challenges in Automotive Networking

The vision of cross-platform use of ECUs,
universal communication capability, interchangeability and reusability of software modules beyond vehicle and OEM
boundaries is fast approaching reality.
Until production matur ity is reached,
however, automotive OEMs and suppliers
still need to overcome a number of
challenges. Two presentations, one by
Volkswagen and the other by Bosch, given
at the Vector Congress in October 2006
serve to explain this.
The topic of AUTOSAR was a common thread throughout the twoday event sponsored by the specialist in developing automotive
electronics, Vector. For the over 350 par ticipants meeting in Stuttgart, the themes of diagnostics, testing, quality and distributed
systems were of primary impor tance. There was general agreement
that the cited visions and future goals could only be achieved by
comprehensive standardization. The well-worn road will continue
to be traveled, where the relative impor tance of software will continue to grow compared to mechatronics and hardware. That is because in the future crucial innovations, specif ic functions and
brand-typical proper ties will be firmly based in the software area.
Mechatronic systems on the other hand will be responsible for basic
functions and emergency back-up systems for example.
This continued growth of electronic systems in the automobile must
however be achieved without increasing the number of control
modules. That assures stable networks and components essential to

achieving reusability of total system solutions across vehicle lines
that have dif ferent Electrical/Electronic infrastructures. The global
challenges lie in attaining quality improvements with simultaneous
cost reduction, creating new business models for handling software
as an independent product with regard to issues of utilization
rights, pricing, product liability, etc., and realizing a professional
organization with a high level of process matur ity.
Activities at Volkswagen and Audi

The current network architecture in Volkswagen vehicles is based on
a total of seven CAN buses plus LIN sub-networks and the K-line.
Currently the focus in standardization work and development ef forts at VW is on standardizing the diagnostic exchange format per
ASAM/ODX, working together with other leading automotive OEMs
Figure 1:
Cur rent network
architecture
at Volk swagen.
6/0
in the HIS (Hersteller initiative Software) interest group, developing and introducing AUTOSAR-conformant software components
and utilizing the FlexRay and MOST bus systems.
ODX has already proven its capabilities in a future-oriented joint
project. The new generations of the Sprinter and Crafter vans from
DaimlerChrysler and Volkswagen are similar from the networking
architecture perspective. An ODX converter processes the ODX diagnostic data generated by the Vector Tool CANdela by DC and uses it
to prepare the diagnostic data for VW.
In introducing AUTOSAR, VW and Audi are taking the approach of
gentle migration and are converting ECUs gradually, ECU by ECU.
Initially there will be dif ferent next generation development levels of the standard software core, in which both AUTOSAR and VW
modules are implemented simultaneously. Adaptation work is focusing on hardware-related areas such as the communication driver, I/O driver and memory driver as well as associated abstraction
modules. After the last migration step, steps will be taken to thoroughly separate the application layer from the underlying layers,
such that it only accesses other system components via the AUTOSAR Runtime Environment (RTE).
Cost and per formance considerations play a key role in decisionmaking processes for future network technologies. Volkswagen is
trimming its large number of CAN networks: LIN and CAN-C are re-
09.02.2010
13:05 Uhr
Seite 2
placing CAN-B. With regard to acceptable bus load, the CAN bus has
already reached its maximum in some instances. Therefore, beginning in 2008, time-triggered FlexRay will assume cer tain challenging networking tasks in distributed systems. In 2009 FlexRay will
be used in an extended application with more than three bus
nodes. MOST has been transporting data in multimedia applications
since 2003 on the Audi A8, and since 2006 on Volkswagen models
too. Additional implementations are planned [1].
Suppliers: Generating customer utility instead of maintaining variety

AUTOSAR also simultaneously represents an oppor tunity and a challenge for Tier-1 suppliers such as Bosch [2]. For suppliers the benefits of a global de-facto AUTOSAR standard lie in the use of standard platforms; this limits the number of versions and facilitates
cost-ef fective mass production. Suppliers can devote their energies
entirely to generating customer utility and do not need to employ
their development resources in numerous inter face modifications.
In implementation seemingly contrary requirements sometimes
need to be satisfied. For example, on the one hand product lines
should demonstrate unique competitive advantages, but at the
same time they should fit trouble-free into dif ferent system environments. System modeling and system design must be kept separate in integrating the devices in a network of ECUs and bus systems. This can only be achieved by very close cooperation with
Figure 2:
Future network
technologies at
Volk swagen.
6/1
09.02.2010
OEMs in design and evaluation of E/E infrastructures. Migration of

todays software architecture to AUTOSAR demands much innovative work by the supplier in adapting development processes, methods, tools and ways of thinking.
In the development process ef forts must be directed toward creating unambiguous def initions of inter faces, completing unfinished
work and deliver ing results; precise software specifications that
prescribe the depth of detail and development levels are essential.
All in all what is required are professional techniques of project and
quality management, project risk assessment and a high matur ity
level among all partners.
Summary and outlook

Key goals of cross-OEM standardization ef forts are quality improvement, cost reduction and ef ficient management of the continuously
growing software share in the value-creating process. The path toward attaining these goals at OEMs and suppliers necessarily involves developing and introducing system components that conform to AUTOSAR, HIS, etc. and facilitate reusability across OEM
boundaries. Simultaneously, power ful bus systems such as FlexRay
will reduce the application field of CAN.
6/2
13:05 Uhr
Seite 3
At the Vector Congress it was made clear that to master the rising
complexities involved in development, administration, data exchange and process management, it is increasingly becoming necessary to turn to massive software support. Vector supports vehicle
OEMs and suppliers in networking the described systems with a universal tool chain and software components, wherein continuous advanced development of the tools is always oriented toward the latest specifications of standards.
[1] Lange, K. (Volkswagen AG): The challenge of networking and software
Implementation of new standards, Vector Congress 2006.
[2] Schnelle, Dr. K.-P. (Robert Bosch GmbH): AUTOSAR Examples of a system architecture from the perspective of an automotive supplier,
Vector Congress 2006.
09.02.2010
13:05 Uhr
Seite 4
ECU Software
Accelerate Your Embedded

Software Development
with standardized basic software. Benefit from scalable software modules for CAN, LIN, FlexRay, J1939 and CANopen used
successfully by many OEMs worldwide.
Development
Distr. Systems
Diagnostics
ECU
Test
> Build upon OSEK- or AUTOSAR-conformant operating systems

which serve as the foundation for a stable implementation.
> Create functionally reliable networks with the communication stacks that most developers rely on.
> Use the Flash Bootloader to update your ECU software in a
controlled process and protect it from third party access.
> Focus on your application development tasks by using
AUTOSAR-conformant basic software modules.
> Improve your efficiency with Vectors tailored consultation
and development services.
ECU
Calibration
ECU
Software
Process
Management

70499 Stuttgart
Tel. +49 7 11 8 06 70-0
www.vector.com
Vector supports you with embedded software, configuration tools and services throughout the ECU development
process.
More Informationen: www.ecu-software.com
09.02.2010
13:07 Uhr
Seite 1
The Universal Gateway ECU

Flexible post-build configuration of AUTOSAR gateways
High flexibility of gateway ECUs is achieved by the post-build principle, since it permits a later configuration at any time
even in late development phases dur ing ECU integration or even in the field. This results in universally deployable ECUs.
Based on the AUTOSAR standard, a method is presented here that describes how the gateway functionality in the finished
ECU can be adapted to new requirements.
Embedded systems can be configured at dif ferent points in time:

Before the source code runs through the build process, the socalled pre-compile configuration occurs. This enables ef ficient implementation of configurations, e.g. var iants, by macros or C preprocessor switches. The link-time configuration is typically used to
generate a library and to link it with ROM constants. Fur thermore,
there is the option of configuration dur ing the run-time of the ECU
(run-time configuration), e.g. by calibration or diagnostic commands. In such cases, the configuration parameters must be stored
in RAM. In contrast to the configuration types already named, postbuild configuration is per formed on ECUs that have already been
built by loading the configuration data into the ECU via a flash
bootloader (Figure 1).
The AUTOSAR standard [1] defines three so-called Configuration
Conformance Classes (CCC), which cover these dif ferent configuration times:
> CCC0 refers to a Pre-Compile Configuration
> CCC1 Link-Time Configuration
> CCC2 Post-Build Configuration.
Just which of these configuration options is in principle available
for a specif ic basic software module depends on the character of
the module. The RTE (Runtime Environment) supports only CCC0,
because it is closely linked to the applications and consists of fully
generated code. The operating system is also configured only at
pre-compile time. Figure 2 shows in the context of the AUTOSAR
layer model which configuration options exist for CAN communication modules.
Figure 1:
Configuration concepts in ECU development
6/4
Figure 2:
Configuration classes in the layer model of an
AUTOSAR ECU
09.02.2010
13:07 Uhr
Seite 2
For the most part, the modules belonging to the communication

stack beneath the RTE support the post-build configuration per
CCC2. Nonetheless, these modules have some pre-compile parameters such as the number of channels, use of data buffers (queues)
and activation of debug modes. These settings must be known at
the time the library is generated. In designing an ECU, a sensible
strategy must be developed for using the post-build capabilities of
neighbor ing modules. For example, it would make little sense to
provide post-build capability to an individual module such as the
PDU Router (PDU-R), while only granting pre-compile configuration
to all other modules.
When is a post-build implemented for gateways?

If the functionality of individual ECUs changes, e.g. dur ing a vehicle
facelift, of ten changes must also be made to the communication
matrix of one or more networks. This is where post-build comes into
play and enables simple adaptation of the basic software responsible for communication between all ECUs of the af fected network.
This eliminates the need for recompiling and linking the code. If a
gateway ECU is designed to be post-build capable, it is easier to fit
it in as a standard ECU in dif ferent vehicle models. Gateway ECUs
per form a major ity of their tasks via the communications basic
software. A vehicle facelift for such ECUs of ten consists of just new
or modified routing relationships, for which all that is needed is a
reconfiguration of the basic software.
The primary motivation for using a post-build configuration is the
fact that it avoids the need for a new build process, and the configuration can be per formed in late development phases dur ing ECU
integration or even in the field. This approach is of special interest
for gateway ECUs.
The gateway ECU as flexible switchboard

The main purpose of a gateway ECU is to distribute communication
data among the individual networks in a vehicle. According to the
AUTOSAR standard, var ious basic software modules of the ECU per form this task. Which modules are used depends on the specif ic
gateway functionality that is needed:
Figure 3:
AUTOSAR basic software modules with gateway
functionality
Nonetheless, it should be noted that in accordance with the

AUTOSAR specification the PDUs must be routed immediately after
they are received. Consequently, the PDU router cannot per form
send type or cycle time conversions. In some cases, however, such a
conversion is necessary. An example of this might be a FlexRay-CAN
gateway that routes a PDU from a FlexRay cluster to a CAN network
as a CAN message. In this case, the gateway ECU must for example
conform to minimum transmission delay requirements (debounce
time) for the CAN message. In such cases, the PDUs are therefore
routed directly to the COM layer, which then assumes this task.
TP gateway
PDU gateway
The PDU gateway is a part of the PDU router (Figure 3). It routes entire data packets, known as Protocol Data Units (PDUs), from one
network to another. This principle assumes that the PDUs are defined identically on both the source and target networks, i.e. they
must agree in length and contents. This means that data can also
be exchanged between dif ferent bus systems such as CAN, LIN or
FlexRay.
Another task of the PDU router is to route transport protocol data.

This comes into play, for example, if the extensive diagnostic data
of an ECU need to be automatically transferred from one network to
another. This involves receiving the data via the Transport Protocol
(TP) and resending it. At first, the transmission occurs above the TP
(Layer 4 in the ISO/OSI layers model), and this enables a conversion to dif ferent addressing methods and var ious bus systems. To
keep delays and RAM requirements in the gateway as low as possible,
6/5
09.02.2010
the TP gateway supports so-called on-the-fly routing: The gateway does not wait until all TP data have been received, rather it already begins to resend the data at an earlier time point. Consequently, it receives and sends simultaneously.
Signal gateway
Of ten just individual signals are needed on the other network. In
this case, the gateway does not transfer the entire PDU, but only
sends individual signals to the other bus. To do this, it first disassembles a received PDU into individual signals, so that it can then
assemble them into one or more send PDUs. Besides modifying the
signal composition and signal positions within a PDU, the send type
and cycle time can also be changed. This method is also used when
a PDU should contain both routed signals and signals generated directly in the gateway ECU.
Technical aspects of post-build configuration

Data structures for the post-build configurable data essentially
have two dif ferent types of layouts (Figure 4). In the non-fragmented
var iant 1, the data structures are arranged one directly after another in memory. The individual data structures are accessed via an indirection table located at a static position. The data structures on
the other hand may vary in size depending on the post-build configuration. The remaining memory is a contiguous block that is
Figure 4:
Data structures for post-build configuration
6/6
13:07 Uhr
Seite 3
available for other purposes. However, the basic software modules

are highly dependent with respect to their implementation. If the basic software originates from dif ferent software suppliers, this var iant
generates a high coordination needs and is therefore impractical.
In the fragmented var iant 2, the data structures are always placed
at a static position in memory. Here, at the time of design, an assumption is made concerning the largest possible memory usage of
individual data structures. In practice, some unused memory between the data structures remains. With regard to runtime behavior, var iant 2 is more ef ficient, since no indirection is needed in
data access. Despite the fragmentation, this var iant also of fers
advantages in terms of memory ef ficiency, since an indirection
table is unnecessary.
The use of post-build data structures has an enormous ef fect on the
design of the basic software modules. In the case of the pre-compile configuration, for example, the separation of code and data is
not required. This makes it easier to implement configuration settings very ef ficiently with macros or preprocessor switches and to
generate optimized C functions with the help of code generators.
The principle of the post-build configuration, on the other hand,
requires strict separation of code and data for post-build parameters. A generator is only available for generating constants tables.
The C functions are static. Figure 5 shows how the dif ferent configuration concepts appear based on code examples.
09.02.2010
13:07 Uhr
Seite 4
THE UNIVERSAL GATEWAY ECU
Figure 5:
Code examples for dif ferent configuration concepts
A gateway ECU requires knowledge of large numbers of signals or

messages. This information exists in the form of data structures in
the ECUs memory. As a result, in gateway ECUs the communication
layers in the software architecture take up a considerable share of
memory and runtime resources. Even when the more ef ficient var iant 2 is selected, the post-build capable layout of the ECU typically
causes increased resource requirements.
A tool chain for post-build configuration of gateway ECUs

Besides the aspects of memory and runtime resources in the ECU,
the post-build principle also requires new processes to coordinate
configuration parameters between par ticipating development partners and exchange them reliably. One impor tant source of support
here is a well-functioning tool chain. Figure 6 shows the tool chain
from Vector Informatik, which can also be used for post-build configuration of gateway ECUs.
Figure 6:
Vector tool chain for
the post-build
configuration
6/7
09.02.2010
At the beginning of a development project, the ECU supplier sets

up the project based on the Pre-Config1 parameter set. Vector provides this parameter set along with the base software delivery for
the ECU, and it contains pre-compile parameters that do not have
any ef fect on the post-build configuration. Examples of this are
general settings and use of the Development Error Tracer (DET).
In coordination with the ECU supplier, the automotive OEM provides
the Pre-Config2 parameter set and an initial network description
(database). The Pre-Config2 parameter set contains those pre-compile and link-time parameters that have an ef fect on the post-build
process and need to be defined in advance. Examples of this are the
addresses of post-build data in the ECU, compiler options and maximum memory size (Flash and RAM). The initial network description,
which the automotive OEM might create with the DaVinci Network
Designer tool, for example, contains all signals relevant to the ECU.
In the case of a gateway ECU, the routing relationships between the
networks are also described there.
The ECU supplier uses the GENy tool to configure and generate the
basic software using this input information. The routing information is prepared in the form of generated data structures (tables)
for the individual basic software modules. This provides a foundation for developing the ECU based on the initial network description.
Dur ing the actual post-build process, these tables must be regenerated and exchanged in the ECU. The basis for this is a modified network description by the automotive OEM. If the updated tables now
exist in binary format and indeed in precisely the same form as
the compiler would have created them then another compiling
and linking run is obsolete. The knowledge about the compiler behavior when generating the binary format is stored in GENy. This
binary file is now converted to a standard hex format and is loaded
into the ECU via the CANfbl flash bootloader. If the pre-config information is known to the automotive OEM, the OEM itself can also
per form the post-build process directly.
6/8
13:07 Uhr
Seite 5
Summary
The post-build process provides flexibility when changes are made
in the communication description. Configuration is even possible in
late development phases dur ing ECU integration or in the field. This
approach is especially useful for gateway ECUs, since it is possible
to adapt them to modified network conditions without having to
change the complete application code. However, the increased resource requirements must be taken into account. In any event, a
gateway ECU is an interesting candidate for the post-build process,
at least dur ing the development phase.
Reference:
[1] AUTOSAR specifications: www.autosar.org
Hartmut Hrner
studied Electrical Engineer ing at the
University of Stuttgart from 1987 to 1992.
After wards, he worked as a software developer for ATM Test Systems. In 1998,
Mr. Hrner came to Vector where he is the
team leader responsible for the development
of embedded software components. Hartmut
Hrner represents Vector on var ious standards
working committees (OSEK, ISO, AUTOSAR).
09.02.2010
13:07 Uhr
Seite 6
Start your Series Development

with AUTOSAR
Enjoy the benefits of field-tested modules that can be used right away:
> Efficiency through reusability and time savings
> Quality through tried-and tested use in serial projects
> Openness through the option of optimally integrating
third-party components
> Flexibility to convert to AUTOSAR step-by-step
> Focus on application development
We create your AUTOSAR solution using expertise and commitment.
Base software and high-performance tools integrated in their own
software architecture.
For more information, please visit: www.autosar-solutions.com

70499 Stuttgart
Tel. +49 (0) 7 11 / 8 06 70-0
09.02.2010
13:10 Uhr
Seite 1
Early Migration creates Oppor tunities for Innovations

Mix of Individual Software and AUTOSAR Components
in Vehicle Electronics
ECU development in the motor vehicle is evolving rapidly.
This ar ticle sheds light on one impor tant aspect:
The introduction of standardized basic software defined
by the AUTOSAR development partnership. If AUTOSAR
software components are added to the overall architecture
in a stepwise and dif ferentiated manner, this assures
quality enhancements.
At the beginning of 2007, the AUTOSAR development partnership

defined, in its Release 2.1, a practice-tested software architecture
that is used as a foundation for developing reusable applications.
With publication of these specifications, in the future it will be possible for all companies belonging to the AUTOSAR development
partnership to develop AUTOSAR-conformant components. However, its practical implementation is not trivial. The transition from
individual software to standard software has to be well-planned
and is cer tainly only conceivable if a stepwise approach is taken.
The AUTOSAR philosophy and description language create a diverse
environment for using standardized software. In practice, this may
be a mixed installation of AUTOSAR and non-AUTOSAR components
or an integration of basic software for specif ic platforms by a number of dif ferent software suppliers. For both types of implementation, it is necessary to clar ify and define the relevant constraints
from var ious perspectives.
Vehicle perspective
From the OEM perspective, basic platforms, technological platforms, etc. are being developed, from which the next generations
of cars will be derived. The underlying goal here is to integrate one
and the same ECU in many vehicles and thereby reduce costs. At the
same time, the quality and the stability of the vehicle electronics
should be improved. This results in a dilemma between the imponderables of a newly introduced technology and the stability of the
product.
Architectural perspectiv
From the point of view of an ECU individual software components
are discernible. At the same time, two contradictory approaches are
being followed with regard to the base software of todays ECUs. On
the one hand, many OEMs require specif ic software components or
at least they specify them. On the other hand, control module producers are striving internally to always use the same architecture
for a control module platform. Added to this is the fact that the degree of standardization of the software is not as comprehensive as
Figure 1:
Ear ly introduction of
a uniform inter face
and RTE simplifies
migration.
6/10
described by AUTOSAR. The goal here is to apply a standard to software that does not serve the purpose of competitive dif ferentiation, thereby creating space for new innovations. Optimally, low investment costs would be incurred by new tools, since those tools already in service can for the most part be reused.
Clear migration strategy as factor in success

When these two perspectives are applied to a decision on introducing AUTOSAR, it makes sense to select a multistage approach.
09.02.2010
13:10 Uhr
Seite 2
Stage II - Replace:
Non-AUTOSAR components can now be replaced gradually by AUTOSAR components without putting the overall architecture at risk or
requir ing reprogramming of other modules. The goal here is to set
up an AUTOSAR architecture and use the appropriate tools. Initiated in individual ECUs, in the end the entire vehicle is conceptualized with AUTOSAR software, starting with system design and ending with integration.
Using the AUTOSAR architecture in designing new ECUs

Stage I Set up the architecture and expand:
The first step is to compare the existing custom software and the
AUTOSAR architecture. After analyzing overlaps and integration potentials, a decision is made regarding which modules will be preserved and which ones can be replaced by standard software. At
this stage it is recommended that a separating layer be introduced
between application software and base software as well as a standardized inter face. The so-called Runtime Environment (RTE) serves
as the link for the necessary data exchange, and as a buffer with
defined inter face it enables modular programming without dependencies. This is how AUTOSAR components can be integrated without
making additional changes to the custom and application software.
The custom software is linked to the system architecture via an Adaptation Layer to enable data exchange with the AUTOSAR components via the RTE; see Figure 1.
To minimize cost and ef fort and arrive at an optimal overall solution, it is helpful at this point to integrate the custom software in
the configuration tools.
Figure 2:
Integration of custom software in the AUTOSAR
architecture.
As implied in Figure 2, essential parts of the individual software can

also be reused in the framework of an AUTOSAR architecture. They
are then linked to the application via an adaptation layer as a complex device driver.
An overlap matrix shows the por tions in which AUTOSAR software
can be introduced without great risk. Primarily, the memory section
and the IO hardware abstraction can be migrated smoothly. Cluster
memory management in par ticular has very clear and easy-to-use
inter faces that enable its early migration to new ECUs.
In communication and diagnostics, on the other hand, there are
considerable overlaps between proprietary vehicle software and
the standard modules of the AUTOSAR basic software. In the interest of stability in the vehicle, a more conservative approach is required here. Many OEMs utilize platform ECUs, in which existing
software modules are transferred to new vehicle models. One implication is that the network and communications strategy cannot be
changed over the short term. In the case of an immediate migration, ECU calibration and off-board diagnostics would also need to
be adapted, which in practice would lead to signif icant problems.
Therefore, the simplest path is to use the existing communication
stack in the AUTOSAR environment too. This stack can be linked to
the RTE via an adaptation layer.
Vector has the necessary expertise in this area and can propose the
right solutions for creating such mixed architectures or supply them
to the customer. For example, the familiar XCP protocol can be integrated in a migration architecture so that existing measurement
and calibration tools such as CANape can be used.
The described approach is not a pure top-down approach, since at
many points AUTOSAR software can even be integrated on lower
hardware-related layers. Its modular structure and defined inter faces help in implementing the standard software on the SPAL level
without af fecting the upper layers. This of fers an enormous advantage with regard to reuse.
Vector Informatik utilizes the concept of Product Cluster ing here.
Based on AUTOSAR specifications, the products of fered range over
a number of layers and provide total solutions for memory, commu-
6/11
09.02.2010
nication, diagnostic and system areas. These are independently

functioning areas, some of which can also be implemented without
AUTOSAR architecture. Cluster memory for example can be integrated quickly and easily in many ECU applications; see Figure 3.
Support by tools
An impor tant pillar in the introduction of AUTOSAR relates to the
tools. They must be able to operate the AUTOSAR inter faces, yet
they must remain open to integration of third-par ty components.
Above all, configuration tools should be able to master this challenge and also support the user in validation of the system configuration.
The tool world servicing AUTOSAR can be subdivided into three categories: Design, configuration and test/simulation. Above all, suitable test instruments are an essential component for successful development. An ECU operates as a part of a whole. Checking for and
assur ing consistency in the overall system requires a high-per formance simulation tool. Vector Informatik GmbH has come to grips
with these requirements and can make a contribution to the success of AUTOSAR with its comprehensive tool solutions such as the
DaVinci Tool Suite, MICROSAR Configuration Suite and CANoe. Support in the context of project work and consultation complement
the products of fered.
13:10 Uhr
Seite 3
Summary
When considered from dif ferent points of view, a stepwise introduction of the standard components defined by the AUTOSAR development partnership into an individual companys software architecture appears to be the correct path. This approach guarantees quality and consistency. Proper tools support this process. Gradual migration instead of an immediate total conversion leads to an overall
AUTOSAR solution in the vehicle that minimizes risks. Vectors expertise and many years of experience lend support to this process.
Peter Schiekofer
(Graduate Engineer) has been employed at
Vector since May 2006. He manages Vectors
Regensburg subsidiary and is responsible for
advanced technical development of AUTOSAR
solutions. As an active working par ticipant
on Working Packages WP 1.1.2 and WP 20 of
the AUTOSAR Development Partnership he is
directly involved with the new technology.
Tel. +49-941/20865-101,
Fax +49-941/20865-111,
E-mail:
peter.schiekofer@vector-informatik.de
Figure 3:
Vector of fers MICROSAR, which
contains the entire range of
AUTOSAR-BSW including RTE.
6/12
09.02.2010
13:10 Uhr
Seite 4
6/13
09.02.2010
13:10 Uhr
Seite 1
AUTOSAR on its Way to Production

To master the growing complexity of software in modern vehicles, automotive OEMs are increasingly developing their electronic systems based on AUTOSAR. The standards created by this development partnership simplify development processes
and make ECU software reusable. Since its introduction in 2004, this innovative and pioneering technology has been tested
in many evaluation projects and is now entering an implementation phase in production ECUs. AUTOSAR standard software
covers the current state of technology and is undergoing continual advanced development in new releases.
The automotive industry is being confronted with new times.
Growth in the number of complex vehicle functions is making the
development of automotive electronics increasingly more extensive
and complicated. Customer wishes, e.g. for more var iants and
equipment variety in the vehicle, as well as non-functional requirements such as diagnostic capability and availability, are requir ing
more intensive ECU development processes. Vehicles, in par ticular
luxury vehicles, may have more than approx. 1,000 software functions, several vehicle electrical networks and more than 70 ECUs.
Due to the variety of hardware platforms used in this field, ECU
software dependencies on the hardware and system configurations
being used has become problematic. Each change to one of these
constraints requires reprogramming or at least modification of the
software.
To make the complexity of ECU software development manageable,
the AUTOSAR development partnership has defined a practice-tested software architecture that serves as a foundation for developing
reusable applications. This open standard for system architecture
created by automotive OEMs, suppliers and other companies in the
global software, semiconductor and electronics industries lets
users avoid proprietary solutions that would result in increasingly
high development cost and effort.
AUTOSAR subdivides the electronics architecture into a number of
layers and modules. With the simultaneous def inition of inter faces,
AUTOSAR creates standards for easy exchange of software components or hardware platforms. The development partnership not only
provides specifications for the base software modules. It also offers
a methodology for developing applications and distributed systems. This methodology begins with a model-based description of
the software applications and the distributed system, and ideally
ends in an automatically generated and reproducible test. This formal approach simplifies the use of a universal tool chain.
is abstracted and subdivided into several layers (Figure 1). The connection to the actual microcontroller, i.e. the physical foundation,
is represented by the Microcontroller Abstraction Layer, which maps
the microcontrollers functions and periphery. It defines inter faces
for memory, the I/O driver and its communication connections. In
this layer, features that the microcontroller does not offer may also
be emulated in software. The second layer that lies above this is the
ECU Abstraction Layer. It establishes die ECU-specif ic hardware layout and provides drivers for the periphery external to the ECU, for
example. In another layer, the Services Layer, var ious basic services
are represented such as network services, memory management,
bus communication services and the operating system. This layer is
already largely independent of the hardware. The RTE represents
the fourth layer. This is where the actual separation of application
and basic software (BSW) is made. The RTE handles integration of
the application software and regulates the exchange of data between the application and the BSW. It is only at this layer that reuse
of already written application software is possible, because the
defined inter faces make it possible to develop the application software without special knowledge of the hardware to be used at a
later time, and the software can be used for any other AUTOSARconformant ECUs.
The so-called Vir tual Functional Bus (VFB) forms the basis for configuration of the layers. All components of the vehicles electronics
communicate in an abstracted view via this bus. The software components use ports for this, whose inter faces can be defined as port
inter faces. Connectors connect the ports. It is irrelevant to the VFB
whether this is a connection within an ECU or a connection via an
external bus. This is not decided until the final system layout is
made and specif ic functions are assigned to a specif ic ECU.
A full three years after its start, the AUTOSAR development partnership published Release 2.1 at the beginning of 2007. A stable level
was reached with this release, and it has been tested in several validation projects for its practical utility. At many businesses, the
action item of AUTOSAR evaluation has been successfully completed. Now it is ready to be implemented in concrete production
ECUs.
AUTOSAR Architecture
To realize the objectives of AUTOSAR separation of the application
software from basic modules and functions the vehicle electronics
6/14
Figure 1:
AUTOSAR layer model for ECU software.
The software component itself does not require any knowledge of

this later distribution, and it can therefore be developed independent of it. The component is subdivided into executable units, socalled Runnable Entities, which are executed like procedures when
a specif ic event occurs. Such an event might be the arrival of a new
sensor value or a periodic activation, for example. The description
of the electronic system formulated from the perspective of the VFB
defines the inter faces of the specif ic software components. As a
result, the application components can be developed independent
of the specif ic ECU.
The counterpart on the ECU is the RTE. It guarantees access to
I/Os, memory and other basic services. Using the model-based
description, the RTE is generated ECU-specif ically, which means
that it can be adapted to dif ferent requirements while economizing
on resources.
Methodology
Besides defining the ECUs software architecture, the AUTOSAR
standard also defines a methodology to help in the development of
AUTOSAR systems. Conformance to a structured creation process is
recognized as an impor tant precondition in creating error-free
software. Deficiencies in the requirements list are detected early,
reuse and porting of software components is simplified, and the
overall system is more reliable. Nonetheless, this methodology also
allows cer tain freedoms: for example, users can decide whether to
use a top-down approach or a bottom-up development.
09.02.2010
13:10 Uhr
Seite 2
The AUTOSAR Initiative provides universal support for the software

development process by tools. Mature tools are used for structured
implementation of requirements and their consistent management;
configurations are systematically created, and complex dependencies are automatically taken into account.
The first step involves formal description of the three primary constituents: Software (SW Components), ECUs (ECU Resources) and
System Constraints.
Suitable editors are used to create a configuration description of
the complete system (Figure 2). This system configuration serves
as the basis for the ECU Configurations that the user creates for the
individual basic software modules with the help of configuration
tools. At the end of the process, multiple generators supply the
ECU-specif ic implementation of the RTE and basic software.
All design and configuration data produced in the development
process are described in a uniform format. AUTOSAR has defined an
XML-based format for this purpose. On the one hand, it guarantees
universality of the development process, and on the other it also
simplifies seamless integration of necessary and auxiliary tools.
Migration
The software architecture of an AUTOSAR ECU is not monolithic,
rather it consists of a number of standard modules with well-defined inter faces. This enables implementation of migration solutions that offer a risk-free transition to AUTOSAR. Such a migration
solution must typically be worked out project-specif ically. In prac-
Figure 2:
Structural description of the software
components. The
creation process for
AUTOSAR-conformant
software components
is organized in clear ly prescribed development steps.
6/15
09.02.2010
tice, this may involve a mixed configuration of standard AUTOSAR

modules and proprietary software.
To work out a migration solution, one begins by compar ing the
existing custom software and the AUTOSAR architecture. After an
analysis of overlapping functionalities and integration options, a
decision is made regarding which modules will remain and which
ones can be replaced by standard software.
So, it is advisable, for example, to introduce a separation layer between the application and basic software. A potential scenar io in
this case is to prepare the applications as AUTOSAR software components already in early migration phase, and to integrate them via
an RTE. Beneath the RTE, a specif ic adaptation layer is used for
inter facing to the existing basic software (Figure 3).
If parts of the existing basic software are to be replaced by AUTOSAR
basic software, the emphasis should lie on the use of a uniform
configuration tool for both worlds. Vector offers suitable tools
Figure 3:
Ear ly introduction of a uniform inter face and RTE
simplifies migration.
13:10 Uhr
Seite 3
here, which are flexible enough to be used to configure proprietary

basic software too. Non-AUTOSAR modules can now be replaced by
AUTOSAR modules in successive steps, without putting the overall
architecture at risk or requir ing reprogramming to other modules.
Outlook
The current AUTOSAR Release 3.0 represents another step taken to
enhance the quality of the AUTOSAR standard. The continuing involvement of par ticipating companies clearly demonstrates commitment to the goals of the AUTOSAR development partnership. Ideas
are currently being introduced that should become a reality in the
framework of the future Version 4.0 of the AUTOSAR standard.
New ideas related to AUTOSAR are also being generated by tool suppliers. Current developments at Vector are aimed at making AUTOSARbased ECU development as convenient and efficient as possible. One
example is a PC-based test tool for AUTOSAR application components, which serves as an emulator for the AUTOSAR ECU environment on the level of the VFB. This makes it easy to test the implementation code of the AUTOSAR software components on a development PC. Widely used standard tools such as Vectors CANoe may be
used for test execution, visualization dur ing or after testing, and
generation of test reports. Vector supports all phases of the ECU
development process with its full set of AUTOSAR basic software and
a universal tool chain of design and development tools (Figure 4).
The available Vector solution has been tested in practice through its
use in evaluation projects, and it is production-mature for AUTOSAR
Release 2.0 or 2.1 (3.0 too starting in the 2nd quar ter of 2008).
Summary
AUTOSAR is becoming a reality. Var ious OEMs have concrete plans
for implementing AUTOSAR in upcoming vehicle production programs. Vector offers a comprehensive product lineup for this, as
well as basic software and tools related to AUTOSAR. Not only does
this enable the development of pure AUTOSAR systems; it can also
support a stepwise migration toward AUTOSAR.
Matthias Wernicke
(Graduate engineer) is responsible for
product management of the DaVinci Tool
Suite and is also actively engaged in
AUTOSAR standardization work.
Figure 4:
The Vector AUTOSAR solution: From system description to standardized ECU software.
6/16
09.02.2010
13:10 Uhr
Seite 4
6/17

Iterative collaboration between OEM, TIER1 and software supplier
A primary reason for introducing AUTOSAR, besides standardizing the basic software, is to increase reusability of the
functional software. This affects the cooperation between the partners involved as well: OEM, TIER1, semiconductor
manufacturer and software supplier. This first part of a two-part series describes a foundation for successful collaboration:
AUTOSAR-specific exchange formats and tools. In the second part, you will learn about the significance of AUTOSAR for
everyday work in developing ECU software for production projects.
Each OEM has its own functional requirements for the ECUs in its
vehicles, especially when it comes to communication and diagnostics. These requirements are implemented in OEM-specific software.
If a TIER1 supplies an ECU to several OEMs, it must manually modify
the ECU software for each project. Even if the functional software is
already decoupled quite well from the software, so that it can be
adapted to the OEM-specific requirements, this modification effort
is still work intensive and prone to errors. Figure 1 shows how
unmodified functional software is adapted to different vehicle
projects without AUTOSAR.
One goal of AUTOSAR is to minimize these adaptation efforts in
software integration. Therefore, AUTOSAR focuses on consistent
abstraction of the software from the hardware and partitioning of
the software into modules with defined functional scope and
precise interfaces. These modules may be combined and, most significantly, they can be substantially configured to cover the
requirements of different OEMs. This eliminates manual modification of the software and facilitates its reuse. Defined interfaces
make it possible to replace OEM-specific software components (e.g.
for diagnostics) with just minimal effort.
AUTOSAR reference architecture

The AUTOSAR reference architecture is described in the document
AUTOSAR Layered Software Architecture [1]. In this document, the
ECU software is organized into the three parts shown in Figure 2:
> The functional software consists of software components (SWCs).
The SWCs are created, independent of the ECUs, based on a
Virtual Function Bus (VFB), and they communicate with one
another via interfaces.
> The Runtime Environment (RTE) is used for executing the SWCs and
it includes the technical implementation of the VFB in a real ECU.
6/18
09.02.2010 13:27:53 Uhr
> The basic software (BSW) modules handle the basic functions of
an ECU. They also offer higher-end standard services such as
management of ECU states and diagnostic services.
The RTE is the layer between the functional software and the basic
software modules. It provides all interfaces the SWCs need to
access data and services of the BSW modules. Examples are signal
values from the communication network (CAN, LIN or FlexRay), I/O
signals and standard services of the BSW modules. The interfaces
originate from the SWC Description files. Moreover, the RTE handles execution of the SWCs and communication among the SWCs
with the help of the operating system.
The BSW modules are subdivided into three layers per the
AUTOSAR architecture [1]:
> Service Layer
> ECU Abstraction Layer
> Microcontroller Abstraction Layer (MCAL)
The BSW modules of the Service Layer play a special role here,
because they contain standard services for the functional software
that are accessed via special interfaces within the RTE. The second
part of this article, in the next issue, will describe the configuration of these services in greater detail.
The AUTOSAR Release 3.0 defines approx. 50 different configurable basic software modules; some of them are very complex. The
majority contains functions that were already usually present in

previous software architectures, but now they are more precisely
distinguished from one another. Consistent partitioning of functions into individual software modules is what assures the desired
hardware abstraction and scalability for different types of ECUs.
The use of such standard modules increases the quality of the ECU
software. In most cases, this standardization covers the interfaces
as well as functions of the BSW modules. Representing an exception here are the BSW modules for diagnostics. Since diagnostic
processes are very dependent on manufacturing and after-sales
processes at the OEMs, AUTOSAR only defines the interfaces of the
diagnostic modules. This allows OEM-specific implementations of
the diagnostic modules. Vector provides these modules for many
OEMs, and it is the task of the TIER1 supplier to configure and integrate the specific variant.
Both the BSW modules and the RTE are available as software
products from various software suppliers (TIER2), such as the
MICROSAR products from Vector, which offer coverage of all BSW
modules and the RTE per AUTOSAR Release 3.0. Although they are
standard software products, the BSW modules and the RTE must be
adapted to project-specific constraints (OEM, vehicle model, ECU
variant). This involves use of relevant PC-based tools during the
configuration process. For example, the RTE may be configured
with DaVinci Developer and the BSW modules with DaVinci Configurator Pro from Vector.
Figure 1:
Creating ECU software without
AUTOSAR
6/19
09.02.2010 13:27:54 Uhr
AUTOSAR Methodology
The AUTOSAR Consortium has defined a method for developing ECU
software, the AUTOSAR Methodology [2]. This document essentially
subdivides the development process into three activities and standardizes data exchange between development partners with a set
of XML files:
> Activity: Component implementation
The TIER1 or OEM defines the SWCs. For this purpose, it creates an XML file for each SWC, the socalled SWC Description. This file describes the
SWCs interfaces and resource requirements.
Afterwards, the TIER1 or OEM creates the related
C files for the implementation of the SWC.
> Activity: System configuration
The OEM first defines the functional scope of the
entire vehicle based on the SWCs, independent of
the ECUs. The next step is to design the communication networks and distribute SWCs to the available ECUs. The result is saved in the System
Description.
For each ECU, the OEM reduces the System
Description to an ECU Extract of System
Description which the OEM can pass to the supplier (TIER1) of the relevant ECU. This file replaces the DBC, FIBEX or LDF files previously used to
configure the BSW modules.
> Activity: ECU design and configuration

Starting with the ECU Extract of System Description, the TIER1 integrates its own SWCs. This
results in a complete and up-to-date ECU Extract
of System Description, which now contains the
description of all SWCs (from OEM and TIER1) of
an ECU.
Another prerequisite for ECU configuration is the
existence of the BSW Module Description files,
which contain the definition of the data structures and all configurable parameters of a BSW
module. These files are implementation-specific
and along with the generators and the static
code are part of the BSW modules.
Afterwards, the TIER1 creates the initial ECU
Configuration Description (activity 2 in Figure 3)
based on the current ECU Extract of System
Descriptionand the BSW Module Description
files. Then the TIER1 begins to configure the ECU
and documents it in the ECU Configuration
Description. The TIER1 uses suitable tools for
configuring and checking parameters of the BSW
modules and the RTE for this purpose (activities 3
and 4 in Figure 3). The ECU Configuration
Description is the foundation for ECU-specific
generation of the RTE and the BSW modules by
the relevant generators.
Figure 2:
AUTOSAR architecture of an ECU
6/20
09.02.2010 13:27:54 Uhr
AUTOSAR: NEW PATHS TO ECU SOFTWARE
The AUTOSAR method is flexible and suitable for satisfying the

practical requirements of different projects or different OEMs. For
example, use of SWCs in the System Description is optional.
Figure 3 shows based on the example of the tools DaVinci
Developer and DaVinci Configurator Pro from Vector how the ECU
design and configuration activity can be implemented with tool
support.
For configuration of the BSW modules, the TIER1 needs the support of a universal tool with user-friendly functions. That is why
Vector developed DaVinci Configurator Pro. It supports three use
cases:
> Configuration of MICROSAR BSW modules from Vector
> Configuration of AUTOSAR BSW modules from third-party
manufacturers
> Configuration of software modules you have created yoursel
Configuring and integrating all software components

During the configuration process defined in AUTOSAR, the TIER1
selects from its component collection those SWCs it needs for
the ECUs functionality. Afterwards the TIER1 integrates them in its
ECU, together with the BSW modules and RTE. This shifts the primary work of integrating the ECU software from manual code adaptation to tool supported configuration of the BSW modules and the
RTE.
Since the current level of the AUTOSAR specifications still has
some room for interpretation, from todays perspective it is advisable to procure either the entire BSW package, or at least defined
BSW clusters, from a single source. The advantage is that the software supplier (TIER2) can already perform an integration test on
these modules. However, it is also possible to procure individual
modules from different TIER2 suppliers or use modified BSW modules. This increases integration effort, however, since both functional integration and integration in the configuration tools need
to be performed.
Essentially, all MICROSAR BSW modules are tested within systematic integration tests. As an integration partner, Vector can extend
its integration services to software modules from thirdparty
producers, such as MCAL drivers, upon request.
MICROSAR BSW modules are configured by using a graphical user

interface that shows the complex interrelationships of the configuration parameters in simplified form. Furthermore, parameter
selection is limited to valid input values, and this prevents setting
implausible values.
The Generic Configuration Editor (GCE) defined in AUTOSAR is
included with DaVinci Configurator Pro to configure the BSW modules from third-party producers. As an alternative, the TIER1 supplier may choose to develop a user-friendly and integrated configuration user interface for these modules itself. This may also be done
with the newly developed DaVinci Configurator Kit. It is used to
create BSW Module Description files for the software modules,
define user-friendly user interfaces, establish validation rules and
create code generators for generating the executable code. The
TIER1 can also use this approach to configure its own BSW modules,
e.g. complex device drivers.
Both DaVinci Configurator Pro and DaVinci Developer contain validation rules that supplement the AUTOSAR method. They ensure that
individual parameters as well as complex parameter groups and their
interdependencies are validated and that the ECU Configuration
Description is generated consistently. This consistency is essential
for subsequent generation of the RTE and the BSW modules.
Figure 3:
Tool-supported
integration of
SWCs and configuration of RTE and
BSW modules per
AUTOSAR
methodology
6/21
09.02.2010 13:27:54 Uhr
Pascale Morizur (Dipl.-Ing.)

studied Physics-Electronics at the Grande
Ecole ICPI in Lyon (France). After graduating
in 1986, she worked for 10 years in advanced
development for CAN, J1939 and diagnostics
at MAN Commercial Vehicles. Since 2005, she
has been employed at Vector as Product
Manager in the area of Embedded Software
Components.
Tel. +49 (0)711/80670-2211,
Fax +49 (0)711/80670-111,
E-mail: pascale.morizur@vector.com
In the second part of this article, you will learn based on examples of selected use cases how the exchange files and configuration tools are used in practice. The process of creating a complete
set of AUTOSAR-conformant ECU software for a specific OEM is
explained, and the article describes how to maintain the software
over time or modify it for a different OEM.
Elektronik automotive, 11/2009
Matthias Wernicke (Dipl.-Ing. (FH))

upon graduating in Industrial Electronics at
the Polytechnical College at Ulm, was
employed for four years at the Daimler
Research Center in Ulm, Germany. Since early
2000 he has been working at Vector Informatik in Stuttgart, developing methods and
tools for the design of distributed electronic
functions in motor vehicles. Today he is
responsible for product management of
DaVinci AUTOSAR tools.
All Figures:
Literature:
[1] Layered Software Architecture:
http://www.autosar.org/download/specs_aktuell/AUTOSAR_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR Methodology:
http://www.autosar.org/download/specs_aktuell/AUTOSAR_Methodology.
pdf
Justus Maier (Dipl.-Inf. (FH))

studied Computer Science in Regensburg. He
began his professional career as a developer
of standardized software in the insurance
industry. For 8 years he was involved in
design and advanced development of tools
for ECU configuration in the AUTOSAR field.
He has been employed at Vector since 2006
as technical Product Manager for DaVinci
Configurator Pro.
Tel. +49 (0)941/20865-451,
Fax +49 (0)941/20865-111
E-mail: justus.maier@vector.com
Links:
Product information about AUTOSAR: www.autosar-solutions.com
>> Your Contact:

Germany and all countries, not named below
Vector Informatik GmbH, Stuttgart, Germany, www.vector.com
France, Belgium, Luxembourg
Vector France, Paris, France, www.vector-france.com
Sweden, Denmark, Norway, Finland, Iceland
VecScan AB, Gteborg, Sweden, www.vector-scandinavia.com
Great Britain
Vector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk
USA, Canada, Mexico
Vector CANtech, Inc., Detroit, USA, www.vector-cantech.com
Japan
Vector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp
Korea
Vector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr
India
Vector Informatik India Prv. Ltd., Pune, India, www.vector.in
E-Mail Contact
info@vector.com
6/22
09.02.2010 13:27:55 Uhr
6/23
09.02.2010 13:27:56 Uhr

AUTOSAR in Practice Life Cycle of AUTOSAR ECU Software
The first part of the article covers the structure of AUTOSAR-conformant ECU software, the AUTOSAR development method
and helpful auxiliary tool support. The second part of the article presents realistic scenarios illustrating how AUTOSAR ECU
software is maintained over its life cycle.
During the development of an AUTOSAR ECU, code generators are
used to adapt the basic software (BSW) and runtime environment
(RTE) to specific ECU requirements. Generation is based on the following extensive description files mentioned in the first part of the
article:
> The ECU Extract of System Description contains the ECUspecific section of the overall system.
> The SWC Description describes the interfaces and structure of
the AUTOSAR software components (SWCs), and it may already
be included in the ECU Extract of System Description.
> The ECU Configuration Description contains the configuration
of the BSW modules and RTE.
> The BSW Module Description describes the configurable
parameters of a BSW module.
The challenge for the developer is to keep these description files
consistent while avoiding the need to recreate the whole configuration whenever a change is made. In performing this task, it is
helpful to use configuration tools that support iterative work processes during an ECU development project. Typical scenarios and
change cases are described as well as having work steps explained
based on the Vector tools DaVinci Developer and DaVinci Configurator Pro.
New development of software components (SWCs)

Depending on the OEM, the ECU Extract of System Description
might already contain the interfaces of SWCs. In some cases, these
SWCs are still incomplete. For example, OEM-specified application
interfaces may be included, but not the implementation description (runnable entities) or interfaces to the standard services of
the BSW modules. The Tier1 developer can add this missing specification with the help of a tool such as DaVinci Developer. The Tier1
may also create its own SWCs (Step D1 in Figure 4).
There are two different ways to implement the SWCs: either manually based on a generated code template or with the help of model-based development (MBD) tools such as MATLAB/Simulink
EmbeddedCoder or TargetLink. The SWC Description is imported
into the MBD tool where it serves as a basis for modeling the SWC.
Code generators are used to automatically generate SWC
implementations.
If SWCs are already available at the Tier1, they can also be integrated in the ECU. This involves importing the relevant SWC
Description and linking the SWC to the other SWCs of the ECU
(Step D2).
Figure 4:
Development of
functional software consisting of
multiple SWCs
6/24
09.02.2010 13:27:36 Uhr
In a separate integration step, data elements of the SWC interfaces are assigned to bus signals (data mapping) provided that
the OEM has not already defined such a mapping in the ECU Extract
of System Description.
Typically, the ECU Extract of System Description will change a
number of times over the course of a project. When the Tier1
receives a new version, the SWCs it contains might also be modified. A special Update function makes it possible to accept changes
in DaVinci Developer without losing any extensions previously
made by the Tier1, such as implementation descriptions or interfaces to standard services.
Configuration of standard AUTOSAR services

One challenge arising in the configuration of AUTOSAR ECUs is how
to configure the standard services of the BSW modules. Within the
ECU Extract of System Configuration, the services are represented by special SWCs, the so-called service components. These service
components are created and integrated with the SWCs by what is
referred to as Service Mapping, which can be performed automatically with tool support (Step D3).
In the top-down approach, the need for services is determined
from the entire functional software, and the services of the BSW
modules are configured accordingly. This approach makes sense for
those services that are not typically specified by the OEM in detail.
Examples are services of the NVM (Non-Volatile Memory Manager)
or the ECUM (ECU Manager).
In the bottom-up method, the service is first configured in the
BSW module, e.g. based on OEM requirements. The SWCs are then
extended to match the service configuration. An example of this is
the DCM (Diagnostic Communication Manager).
Just like the services, the ECUs I/O interfaces are also represented by a special SWC the I/O Hardware Abstraction
Component. This SWC can also be created by a top-down or bottom-up approach.

At the end of the integration process, the Tier1 gets an updated
ECU Extract of System Description. Besides the OEMs original
version, the file now also contains content defined by the Tier1 and
is fully validated.
Modification of the RTE after changing SWCs

If only the implementation of a SWC changes without affecting the
SWCs interfaces or structure, neither the RTE nor the basic software would need to be reconfigured. However, if the structure of a
SWC changes, e.g. due to the addition of a new runnable entity, the
RTE configuration must be modified. This involves assigning the
newly added runnable entity to a task. After this modification has
been made (Step D4 in Figure 5), the RTE configuration is validated
(Step D5).
The DaVinci Developer supports this process with detailed error
messages and recommended corrections. For example, inconsistencies are reported so that the Tier1 can correct the SWC Description or RTE configuration.
Incorporating changed communication data from the OEM

A typical change scenario is updating the communication data of
an ECU, e.g. because the distribution of signals to messages has
changed. Such a change is only relevant to those BSW modules
related to communication and does not require any changes to the
RTE or SWCs.
Figure 6 shows the work steps that are performed to accept the
changed communication data. The BSW modules can be adapted
automatically: First, a new ECU Configuration Description is generated, and the contents of the old ECU Configuration Description
Figure 5:
Work steps in configuring the RTE
6/25
09.02.2010 13:27:36 Uhr
are converted to the new ECU Configuration Description (Step

C1-2). All parameter values unaffected by the change are automatically accepted. Only the parameters of the new or modified signals
or messages are then configured in Step C3. Finally, to ensure that
all parameter values are consistent, the new ECU Configuration
Description is validated in Step C4.
As a supplement to the AUTOSAR standard, Vector has implemented an Update function and validation in DaVinci Configurator Pro. If the OEM does not provide an AUTOSAR-conformant ECU
Extract of the System Description, the Tier1 can instead use the
familiar network description formats (DBC, LDF or FIBEX) as inputs
to the DaVinci tools.
Switching over to a different processor or processor type

Thanks to the systematic hardware abstraction offered by AUTOSAR
the TIER1 only needs to replace the affected MCAL modules when
switching over to a different processor device or processor type.
This transition is performed with tool support: The old MCAL modules are removed and the new MCAL modules are added to the project by selecting the new BSWMD files. The new platform-dependent parameter values that were added are checked in DaVinci Configurator Pro and reconfigured by the Tier1 as necessary (Step C3
for each changed MCAL module). Consistency of the ECU Configuration Description is restored by final validation (Step C4).
Especially useful to the Tier1 is the ability to extend the tool
environment, e.g. to support the MCAL modules of future
processors or own BSW modules. This is enabled by the DaVinci

Configurator Kit, which is used to create the Tier1 BSWMD files and
module interface files. They contain definitions of specific configuration interfaces, validation rules or generators for the BSW modules (Steps C5 and C6).
Replacing OEM-specific diagnostics

If an existing ECU configuration is to be used for a different OEM,
the ECUs diagnostic basic software must be replaced, because it is
OEM-specific. This affects the DCM and DEM (Diagnostic Event Manager) BSW modules.
Figure 7 shows how this replacement is made. The Tier1 obtains
the new CDD or ODX file from the OEM. These widely used formats
contain the diagnostic description data for the ECU. They can be
generated with tools such as CANdelaStudio from Vector. DaVinci
Configurator Pro utilizes information from these files to automatically configure diagnostic BSW modules for the ECU (Step C7).
Analogous to the modified diagnostic BSW modules, the DCM and
DEM service components must also be modified and made known to
the application SWCs in a bottom-up process. For this purpose,
DaVinci Configurator Pro takes the ECU Configuration Description
and generates the SWC description files which include service
components for DCM and DEM (Step C8).
The Tier1 can now use DaVinci Developer to generate the service
mapping for all diagnostic services of the new OEM. Validation of
the SWCs ensures that no service is forgotten in the change
Figure 6:
Work steps in
configuring the
basic software
6/26
09.02.2010 13:27:37 Uhr
AUTOSAR: NEW PATHS TO ECU SOFTWARE
process. If the application SWCs does not yet offer the diagnostic
services required by the OEM, they must be extended (Step D1-3),
which in turn requires modification of the RTE (Step D4-5).
Changing I/O signals

In case a new sensor needs to be connected to the ECU the new I/O
signal that it uses must be added to the ECU Configuration
Description. Therefore the Tier1 extends the configuration of the
I/O hardware abstraction in DaVinci Configurator Pro by adding the
new signal (Step C3 in Figure 6) and modifies the pin mapping in
the I/O drivers in the MCAL layer. After successfully validating this
configuration change, an updated SWC is generated for representation of the I/O Hardware Abstraction. By importing this SWC into
DaVinci Developer, the Tier1 can extend the SWCs of the functional
software so that they can access the new sensor.
Advantages of the AUTOSAR configuration process

The AUTOSAR principle configuring instead of programming
enables early validation of the ECU software architecture. This prevents errors from occurring in a late phase. Nonetheless, the
AUTOSAR formats are extraordinarily complex. Good tool support is
essential to handle the changes that are typically required over the
course of a development project.
Figure 7:
Work steps in
modifying the
diagnosticspecific software
parts of an ECU
6/27
09.02.2010 13:27:37 Uhr
Networking Heavy-Duty Vehicles Based on SAE J1939

From Parameter Group to plug-and-play Application
In networking ECUs in heavy-duty vehicles, it is the J1939 protocol that plays a key role. J1939 networks are based on the
CAN bus (high-speed CAN per ISO11898); they are primarily used in powertrain and chassis components. The protocol
creates a uniform basis for communication between electronic control units, and it supports the plug-and-play principle.
Special J1939 tools and software components spare developers from needing to train in the details of the J1939 protocol,
and they improve the quality of the development process.
The J1939 protocol founded in the USA and defined by the Society of Automotive Engineers (SAE) serves above all to preserve a
uniform perspective and uniform handling of the most common
vehicle components of various vehicle types and manufacturers. In
this context, it is interesting to note certain distinct differences
between the European and North-American heavy-duty vehicle
markets. For example, heavy-duty vehicle buyers in the USA have
prescribed to OEMs which components they need to install in specific vehicles. In Europe, on the other hand, it is the OEMs who fully
define the design of the entire vehicle, including the components
and their configuration.
Besides using uniformly defined signals and data formats to
communicate, it is of course important that receivers know how to
interpret the information. Ideally, it should be possible to interconnect individual J1939 components based on a plug-and-play
scheme. Despite all of its standardization aspects, J1939 gives

OEMs sufficient freedom for customized extension of communication. This is especially important in promoting innovations,
because no OEM wants to announce or discuss plans in working
committees before their implementation.
ISO Layers Model decouples the Application from

Transmission Physics
From the perspective of the ISO/OSI network model, J1939 is
essentially based on the Application Layer (Layer 7), Network Layer
(Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1)
(Figure 1). This lets developers work with signals without needing
to be concerned about communication details on the Application
Level, such as details of the transport protocols. J1939
7/0
09.02.2010 13:25:30 Uhr
Figure 1:
The J1939 protocol essentially covers the Application Layer (Layer 7),
Network Layer (Layer 3), Data Link
Layer (Layer 2) and Physical Layer
(Layer 1), so that it is no longer
necessary to be concerned about
communication details when working on the application level.
documentation and definition is oriented toward individual layers,

and this is expressed in the names of the total of 14 documents of
the standard. For example, documents of the 7 series such as
J1939/71 refer to the Applications Layer, document J1939/21
the Data Link Layer, etc.
CAN Message Format in J1939

Although J1939 utilizes normal 29-bit CAN messages with up to 8
bytes of data, here the CAN identifier quasi defines the mask of a
uniform J1939 scheme (Figure 2). This is necessary to assure plugand-play properties. The CAN identifier besides identifying the
useful data with the help of the Parameter Group Number
(PGN) also contains the J1939 ECU address of the sender and if
applicable the address of the receiver too. In addition, the three
most significant bits of the CAN identifier are reserved for the priority field; although these bits do not replace the implicit priority
established by the CAN protocol, they make it possible to organize
the Parameter Groups into up to eight J1939-specific priority levels. These priorities are used to adjust the priority to momentary
application requirements at the time the Parameter Group is transmitted or during an optional ECU configuration phase. This makes
it possible to fine-tune communication to the application without
the SAE protocol permanently setting the priority when the Parameter Group is defined.
Figure 2:
The J1939 message format which
is based on normal 29-bit CAN
messages requires some supplementation to achieve plug-and-play
capability. The CAN identifier quasi
defines the mask of a uniform J1939
scheme.
7/1
09.02.2010 13:25:31 Uhr
The Name says it all: J1939 Device Names

J1939 defines device names that are each represented by a 64-bit
number. When an ECU is switched to active in the plug-and-play
network, the device name serves to identify the device and its functionality. The device name is subdivided into different elements,
between which certain dependencies exist. The independent fields
include the Industry Group and Manufacturer Code. The Industry
Group is used to establish the functions required in the network,
since the J1939 protocol is not only used in conventional heavyduty vehicles but also in vehicles in the agricultural and marine
industries. Each ECU carries one of the SAE assigned Manufacturer
Codes that can be requested from that organization. Since each
device also has a serial number, the complete name over all fields is
unique worldwide, and there are no overlaps.
Since addressability of the devices is inefficient in practice when
64 bit long device names are used, the SAE defines 8-bit addresses
for the individual vehicle components in the heavy-duty vehicle
field; practically these addresses never change over the life of the
components. This does not apply to the agricultural and marine
industries; there the addresses are dynamically negotiated at the
start, based on the device name. The addresses 0 to 127 are
assigned to the most commonly used ECUs such as engine, transmission, retarder, brakes, etc., while the range from 128 to 247 is
reserved for agricultural, marine, construction equipment, etc.
Service tools, OBD scanners, etc. occupy addresses from 248 to
253. Finally, there are the special addresses: 254 to identify devices
that do not have their own address and 255 that is used as a global
address for addressing broadcast messages.
Types of Communication: Point-to-Point or Broadcast

The J1939 protocol supports two communication types: point-topoint transmissions (1:1) are directed to precisely one target
address; they are used for device configuration or ECU commands,

for example. Broadcast messages (1:n), on the other hand, are
simultaneously addressed to all bus nodes, which is practical when
it comes to sending out measured values, error handling and diagnostic purposes.
Flexible Network Topology

J1939 works with a passive bus that is terminated at each of its two
ends with 120 Ohm impedance. The advantage here is that individual ECUs can be connected to the bus via branch lines with a length
of 1 to 3 m. This enables flexible wire harness design, provided that
a total bus length of 40 m is not exceeded. Depending on the physical transmission layer, between 10 and a maximum of 30 nodes may
be connected to the network. J1939 provides uniform diagnostic
access for service testers and on-board diagnostics. Legal requirements specify that a branch line with a length of up to 5 m must be
possible here, e.g. for road tests of the emissions control system.
Bridges can be used to extend J1939 networks to include trailers/
implements, enabling implementation of a separate network there
(Figure 3). In the EU, ISO 11992 has prevailed for this purpose,
while in the USA the Power Line Carrier is state-of-the-art
technology.
Timing Requirements in ECU Design

In designing J1939 ECUs, care should be taken to ensure that no
messages are lost due to hardware or design limitations. At a
baudrate of 250 Kbps, transmission of one bit takes 4 microseconds. With 8 data bytes, a typical message length of about 128 bits
is obtained, yielding a transmission time of about 500 microseconds per CAN message. The shortest message length, however, is
64 bits, i.e. it must be possible to receive messages at intervals of
250 microseconds and process them sufficiently fast. In practice,
Figure 3:
With regard to network topology,
J1939 enables flexible design of
wire harnesses. Individual ECUs can
be connected via branch lines up to
3 m in length.
Bridges make it possible to realize
separate networks on implements
and trailers.
7/2
09.02.2010 13:25:32 Uhr
NETWORKING HEAVY-DUT Y VEHICLES BASED ON SAE J1939
this leads to a high interrupt load due to the CAN controllers often
limited CAN identifier filtering capabilities. Filtering also usually
needs to be implemented in software.
Testing and Diagnostics of J1939 Components and

Systems
In view of the rising number of J1939 ECUs and the fact that software solutions in heavy-duty vehicles are becoming increasingly
complex, a systematic strategy for testing and diagnostics also
continues to gain in importance in the J1939 field. Tests are indispensable in all development phases, from functional tests to integration tests to driving trials in the total vehicle. It is well known
that the later that errors are detected, the more complicated and
expensive it is to correct them. However, it is generally only possible to test ECUs comprehensively after they have been integrated
in the network structure. Consequently, weak points are often not
revealed until very late, unless one relies on the support of proven
software tools right from the start.
Given this situation, the use of specialized tools offers developers substantial simplifications in testing and diagnostic tasks. For
many years now, Vector has been actively involved in SAE J1939
subcommittees and regularly participates in working sessions. With
a universal tool chain for all J1939 projects, it is possible to efficiently solve the most challenging tasks in networking and communication in the heavy-duty vehicle field [1]. Besides development,
testing and analysis tools, embedded software components tailored to the special requirements of J1939-based applications are
available, and customized project work and training events round
out Vectors products and services.
A J1939 extension is available for the widely used CANoe development and test tool; it spares heavy-duty vehicle developers from
needing to train in the details of the J1939 protocol. The package
from Vector extends basic software functionality to cover all necessary protocol-specific features. When CANoe.J1939 is used consistently, the models and databases created in the design phase not
only serve as a foundation for simulation during development, but
also for all tests accompanying development up to and including
later diagnostic tasks (Figure 4). With the help of simulated nodes,
it is possible to set up and execute tests for the ECU to be developed. The tests are further refined during development and are
used in verification of the total system.
Extensive J1939 Test Library

The CANoe Test Feature Set is made up of CAPL test modules, XML
test modules and .NET test modules. They are able to cover all challenges arising in testing tasks of varying complexity, from simple
to difficult test cases. While the C-like script language CAPL is ideal
for creating extensive test scenarios, the primary focus of XML is
on simple parameterization of test patterns and simple generation
of test procedures. That makes it possible to implement application-specific test modules (function libraries) in CAPL and then
generate test control that is individually adapted to the ECU configuration. The J1939-specific extensions in the Test Service
Libraries allow the system react to Parameter Groups (PG) instead
of typical CAN identifiers. They also offer test patterns for J1939
protocol functionality and checks (background monitoring) for
protocol violations. For example, it is possible to test whether the
ECU is able to send all Parameter Groups at the configured cycle
Figure 4:
Tests conducted with the help of
simulations during development
make it possible to detect and correct errors early on in all development phases. The CANoe Test Feature
Set offers extensive testing and
analysis capabilities.
7/3
09.02.2010 13:25:32 Uhr
time under high bus load. Furthermore, it is possible to send faulty

transmissions via the BAM (Broadcast Announce Message) and
CMDT (Connection Mode Data Transfer) transport protocols for test
purposes.
To create the test modules besides the J1939 Test Module Manager and the convenient Test Automation Editor the Option DiVa
is useful. DiVa creates a connection between CANoe and the diagnostic specification tool CANdelaStudio, so that specifications created there can be ideally used in further ECU-specific diagnostic
tests.
Other functions of the Test Feature Set relate to test flow control
and automatic report generation, including statistical information
in XML or HTML format based to individual requirements. Further
options for automating test processes are enabled by the COM
interface, e.g. options relating to flow control, parameter changes
or status queries. CANoe Option J1939 provides a trace window,
J1939 diagnostic monitor and J1939 diagnostic memory access for
diagnostic purposes. The diagnostic monitor supports various
J1939 diagnostic messages, such as DM1 and DM2, and it serves to
display and clear active errors. Also possible is access to memory
areas, objects and parameters as well as periodic object updating
for monitoring purposes.
Integrating Matlab/Simulink Models in J1939 Network

Simulations
Generally, various function models are created for mechanical components such as transmission, powertrain or even the entire vehicle
during the different heavy-duty vehicle development phases. ECU
architectures are initially saved in virtual CANoe function models
and are implemented step-by-step on the final target hardware

platform. CANoe.J1939 can also integrate Matlab/Simulink models
in ECU and network simulations (Figure 5). With the Real-Time
Workshop from Mathworks the user generates a *.DLL for CANoe so
that variable names and units are compatible.
Progressing through the various stages of the V development
model, individual tests and subsystem tests are possible through
final verification of the overall system. This enables early detection
and correction of errors. If an error is found, the automated tests
can be restarted at any time; they minimize the risk of side effects
in error correction. As a result, development is characterized by
short verification cycles, enabling a seamless transition from MIL
(Model in the loop) to SIL (Software in the loop) and then to the
real ECU (HIL Hardware in the loop). If there are exceptional realtime requirements of the simulation platform, a special real-time
version is available with CANoe RT.
Realizing Goals quickly with standardized Embedded

Software Components
Use of CANbedded J1939 software components leads to quick
development results. These components largely relieve developers
of the need to handle all of the details of the J1939 standard, and
they avoid duplicated developments. A key aspect is a central OEMmanaged database containing all elementary information related
to ECU communication. Depending on requirements, this information might be distributed to other working partners, producing
flexible distribution of tasks between the OEM, network specialists
from Vector and suppliers (Figure 6). The latter can use the GENy
configuration tool for specific settings and parameterizations. The
Figure 5:
Not only is CANoe able to simulate
functional models of ECUs during
the development process and integrate models created with
Matlab/Simulink in the scenarios;
at the same time it also serves as a
convenient user-interface.
(Source: Renault Trucks)
7/4
09.02.2010 13:25:32 Uhr
NETWORKING HEAVY-DUT Y VEHICLES BASED ON SAE J1939
results are reduced cost and timing for implementation and testing, compatibility on the CAN bus based on unambiguous signal
interpretation and maximum quality and flexibility in the J1939
communication stack. CANbedded J1939 supports all relevant
microcontrollers and is characterized by low ROM and RAM memory
requirements as well as high runtime efficiency.
Internet links:
[1] J1939 solutions from Vector www.j1939-solutions.com
[2] Download of presentations from J1939 User Day
www.vector-worldwide.com/ud [most of them are German]
Peter Fellmeth
studied at the University of Applied Sciences
in Esslingen, Germany, majoring in Computer
Engineering and specializing in Automation
Technology. He is team leader and product
manager at Vector Informatik GmbH, where
he is responsible for the development of
products and customer-specific projects
related to J1939, ISOBUS, Ethernet and
DeviceNet.
Thomas Lffler
studied Automation Technology at the University of Applied Sciences in Reutlingen,
Germany. He has been employed at Vector
Informatik GmbH since 2000, initially in the
DeviceNet area, and since 2002 in the J1939
and ISOBus area. His areas of specialization
are configuration and generation tools for
embedded software, support of customer
projects and product and protocol training
programs.
Figure 6:
Standard software components of
the CANbedded J1939 package lead
to quick development results
without developers needing to be
concerned with all details of the
J1939 standard. A centrally managed
database avoids duplicated developments and enables optimal work
distribution.
7/5
09.02.2010 13:25:32 Uhr
09.02.2010
13:09 Uhr
Seite 1
CAN and J1939 under Extreme Duty Conditions

Vehicle electronics guarantees functionality in cold, ice and snow
Anyone who has par ticipated in winter sports at one
time or another is familiar
with them: The slope
groomers that tirelessly
prepare the ski slopes and
transport goods to mountain stations or injured persons safely down to the valley. They not only embody a
special species of all-terrain track vehicle, they also
deliver the experience of true high per formance. Vehicle electronics play a decisive role
in the incredible capabilities of these machines. Without electronics neither functionality nor safety nor any other signif icant innovations would be conceivable. This technical
ar ticle of fers insights into the vehicle technology, development process and development tools of the latest generation of PistenBully vehicles from the Kssbohrer Company.
In contrast to conventional off-road vehicles, the technical
challenge for the PistenBully is to master the numerous extreme situations encountered in cold, snow and nighttime
operation. The machine, capable of moving in any direction
on inclines up to 45, covers an area of 96,000 m2/h with its
multiflex tiller. This technology is standard equipment for
duties up to 4,000 m above mean sea level and extreme outside temperatures; the elevation capability of the polar version even reaches up to 6,000 m.
in the cockpit display also provides optimal visibility when

driving in reverse. To support grooming on steep inclines the
vehicles can be optionally equipped with electro-hydraulic
cable drums that carry 1,000 m of cable. A special feature is
free rotation of the drum, allowing the vehicle to turn 360
as of ten as desired. Besides models for use on mountains
and snow, there are also PistenBully versions without a load-
Greatest Safety under Extreme Conditions

Slope grooming is of ten scheduled for evening and nighttime hours, while there are no regular winter sports activities. If vehicle drivers are under way alone in a snowstorm or
fog at high elevations or in Arctic regions, the reliability and
availability of the vehicles can be life preserving factors.
Safety as well as comfortable and fatigue-free steer ing and
controls were therefore key aspects of the vehicle concept.
Intelligent automatic functions support the driver and reduce the number of control inter ventions needed, so that
the driver can concentrate on what is impor tant.
Impact and puncture resistant windshield glass protects the
driver from rock impacts, and a lighting system with a wide
array of running lights, searchlights and working lights turn
night into day. Automatic integration of a rear camera image
7/6
Figure 1:
Up to 620 PistenBullys are produced in Laupheim every
year
09.02.2010
ing platform, versions exclusively used to transport personnel, excavating versions and even versions that can swim.
Kssbohrer produces about 600 to 620 units per year, and
the cost per vehicle lies between 80,000 and 340,000 euros.
Power for Driving, For Ski Lifts and Emergency

Electrical Generators
The vehicles are driven by engines from Mercedes-Benz with
power ratings between 90 HP and 460 HP. The latest PistenBully 600 has a standard 12.8 Liter engine deliver ing 295 kW
(400 HP) and torques of up to 1,900 Nm. Two independent
hydrostatic drive circuits without separate clutches are responsible for tractive power to the right and left sides. The
engine controller delivers the required engine torque when
13:09 Uhr
Seite 8/7
starting up from a stop and prevents adverse events such as

stalling. Simultaneously, load limit control of fers protection
against overloading and over revving of the diesel engine.
A single gas pedal is used to accelerate and decelerate (braking), i.e. there is no working brake, only a parking brake.
Changes in driving direction are achieved by dif ferential
track speeds. Each drive has infinitely var iable output speed
adjustment and its direction of rotation can be reversed. As a
result, the fully electronic steer ing can support turning in
place, pre-selection of driving direction and speed reduction. The steer ing aggressiveness varies with driving
speed; the driver can adjust it to his or hers specif ic needs.
This means that the driving speed can be changed by gas
Figure 2: Over view of CAN networks in the cur rent PistenBully
7/7
09.02.2010
pedal or load limit control without af fecting the turning radius. Wheel sensors enable straight-line and uniform curve
control or asymmetrical steer ing character istics for special
applications.
Nothing runs without vehicle electronics

Electronics is or at least was of ten considered a necessary
evil by conventional machine building companies. The Kssbohrer Company, whose or igins are in the steel building industry, has come full circle in its perspective here. Without
electronics any meaningful interplay between complex vehicle components would be inconceivable. Vehicle electronics
is ever present, from steer ing, control of the engine and hydraulic system, conveniences of vehicle navigation and the
control of implements, to functions for operational data acquisition, telematics and GPS.
Consistent and thorough networking of the vehicle by CAN
(Controller Area Network) was a prerequisite for achieving a
decentralized control structure. This made it possible to rationally combine electronic and mechanical components to
make one control module. In compar ison to earlier PistenBully generations, decentralization has enabled signif icant
reductions in wir ing costs. Nearly all communication is routed over the two primary buses CAN1 and CAN2 (of a total of
five CAN bus lines). While CAN3 is used for external communications in fleet management, the CAN4 and CAN5 systems
13:09 Uhr
Seite 8/8
are reserved for future functions not currently needed, and

they are technically ready to implement them. Additionally,
CAN is utilized for software updates, parameter configuration and in measurement systems. Since all functions can
currently be implemented with CAN, the use of newer communication systems such as FlexRay, LIN or MOST is not currently under discussion. The electrical system is set up to be
fully modular and is uniform across all vehicle var iants. Since
the basic wir ing already considers all current and future options, it is easy to accomplish expansions and retrof its by
means of adapter wire harnesses.
Lots of power electronics, just a few fuses and

no relays
The PistenBully universal PSX control module is responsible
for central control of all functions such as per formance and
power management, engine control, hydraulics of the drive
and tilling pumps, oil flow distribution of the working hydraulics, front and rear, as well as monitor ing of all sensors
and actuators. It is supplemented by the central electronics unit, which besides of fer ing numerous diagnostically capable and short-circuit protected inputs/outputs, also houses other functionality such as central locking, RF remote
control, lighting control and voltage converters for 12 V. The
full load capable unit supplies a summed continuous current
of 640 A at 24 V and thereby achieves a switching capacity of
up to 15 kW. The Central electronics unit has connections
to all five CAN buses. In total there is need for just eight actual fuses; everything else has been implemented to be
short-circuit protected and self-healing without relays.
Maneuver ing is easy and intuitive

Connected to the internal vehicle bus (CAN1) are the controls and display elements of the cockpit. In addition to the
ergonomic semi-circular steer ing wheel, also includes a multifunction display with touchscreen, round CAN instruments,
a Terminal Control Center (TCC) integrated in the arm rest
and a joystick with programmable function buttons.
Figure 3:
Controls and display components in the PistenBully cockpit
7/8
The multifunction display gives momentary information at a

glance on the most impor tant operating states and on driving speed, cable drum tension, engine data, etc. It of fers in-
09.02.2010
13:09 Uhr
Seite 8/9
CAN AND J1939 UN DER EX TREME DU T Y CON DI TIONS
Figure 4:
CANoe as joystick
simulator for testing
hydraulic valves
Figure 5:
CANoe in flash mode
7/9
09.02.2010
tuitive control, on the touchscreen or via the TCC. The operating panel mounted to the right of the driver with its film
keypad lets the user select numerous Pistenbully functions
directly. A joystick is used to control the var ious movements
of the snow blade and of the rear implement carrier as well
as used to set the tilling pressure, cable drum tension, etc.
The joystick is an in-house development, since none of the
commercially available models could satisfy the expectations
of Pistenbully developers.
CAN controls hydraulic module

CAN2 serves as a sensor-actuator bus for engine control and
valve control and an inter face for sensors. The hydraulic valves are driven entirely via CAN, i.e. without supplemental
analog or digital I/O signals. On the part of the sensor/actuator bus, so-called multi-modules provide input channels,
digital outputs, PWM outputs and bridge outputs that are diagnostically capable, short-circuit protected and self-healing. The sensors connected here are all equipped with 4 to
13:09 Uhr
Seite 8/10
20 mA current inter faces to automatically compensate for

contact resistances when electrical connections corrode.
While Kssbohrer utilizes its internal KGF protocol for the
CAN1 functional bus, the J1939 protocol is used on CAN2 for
the drive system. The advantage of standardized drive management based on SAE J1939 is that the drive system can be
built with components from outside suppliers, independent
of the vehicle producer, including a suitable diagnostic system. On the functional side, the proprietary protocol was
used intentionally to prevent unauthor ized manipulations
and simultaneously to protect know-how. That is why it was
also decided not to use the CCP (CAN Calibration Protocol)
standard for the ECU application. The CAN bus systems can
be parameter ized and diagnosed from a laptop.
Safe return to the valley even if the bus fails

It is interesting that X-by-wire systems have already been
used in PistenBully production vehicles since the 1970s, while its implementation in general road vehicles was not even a
Figure 6:
CANoe in measurement data acquisition dur ing vehicle
trials
7/10
09.02.2010
13:09 Uhr
Seite 8/11
CAN AND J1939 UN DER EX TREME DU T Y CON DI TIONS
topic of discussion until decades later. Entirely dif ferent

legal regulations apply to the operation and safety of pure
off-road vehicles not subject to highway vehicle registration,
since the vehicles are used exclusively on private land. If
there is failure of the steer ing potentiometer, driving direction pushbuttons and/or the redundant gas pedal with a
contact less sensor, driving capability is preserved as long as
possible. The vehicle, weighing in at between 7 and 10 metric tons and capable of a maximum speed of 23 km/h, can
then be driven safely back to the valley with emergency running character istics at a throttled-down speed of 5 km/h.
Even if both CAN buses fail the PistenBully remains maneuverable with control via PWM signals.
For the electronics, besides satisfying requirements for harsh
temperature and humidity conditions and mechanical stresses, other special requirements also apply, e.g. with regard to
electromagnetic compatibility. This ensures that the high
field strengths of radio transmitters on mountain peaks will
never impair vehicle functions.
From simulation to real PistenBully electronics

Software development and vehicle calibration cover ing all
control modules are all per formed at the Kssbohrer Company. This lets the producer from Laupheim adapt flexibly to
new operating situations. Since the complexity of the software and the electronic functions is constantly growing,
developers on a project like the PistenBully must rely on

power ful tools for software development too. Over the course of the development process it is essential to per form
design functions, tests and simulations of subsystems and
overall systems. This is where CANoe with the J1939 Option
from Vector comes into play.
CANoes capabilities as a development and simulation tool
range from simulation of a single network node, to testing
and diagnostics, to representation of complete CAN networks. Beginning with initial studies on the purely vir tual
model, the vir tual nodes can gradually be replaced by real
hardware step-by-step over the fur ther course of development. In this case, vehicle functions are executed by a vir tual ECU in an OSEK emulation. Among other things, this
makes it possible to control and display the states of vir tual
sensors and actuators. It is also possible to generate associated control panels automatically.
Short development times

At Kssbohrer some of the uses of CANoe are to simulate bus
loads, function as a measurement tool and parameter ize
ECUs by the proprietary KGF Protocol. The developers use
this protocol to generate diagnostic and setup information
in temperature tests, EMC tests and reaction tests of valve
controls, for example, and this helps them to keep solutions
for production vehicles lean.
Figure 7: Easy fault localization for the driver with OBD
7/11
09.02.2010
The development of dual-channel fan control in the PistenBully was completed in an exceptionally short time without
utilizing real hydraulic pumps, valves or motors. In such cases CANoe realistically simulates all necessary CAN nodes,
sensor signals and ECU information. In ECU setup CANoe enables access to EEPROM contents via an in-house flash protocol. This is easy to reprogram with the integrated programming language CAPL (Communication Access Programming
Language). The EEPROM data stored on the hard drive can be
loaded into the controller at any time.
Indispensable: Real-time capability of development tools

An employee explains: As developers we rely on good tools,
and CANoes reliability is excellent! Real-time capability is
especially impor tant to us. We have already had negative experiences with similar software on another project. It took
days of troubleshooting to finally find out that the tool simply could not keep pace with our sampling rate requirements,
and this led to erroneous results.
In-house user inter faces, panels and other tools that are frequently needed are generally programmed in-house at Kssbohrer using Borland C++. Even in such custom developments CANoe databases always serve as the foundation.
Moreover, CANoe facilitates optimal cooperation with suppliers since the behavior of assemblies can be tested in advance. The PistenBully developers only regret that not all
system suppliers provide CANoe simulations of their products or make them available early on.
Mobility for fine tuning on the slopes

Another impor tant aspect is tool mobility. Since snow conditions are constantly changing, fine tuning of the drive system is of ten per formed locally in the mountains. When it is
impor tant to per fect control loops for the var ious types of
slope preparations and adapt them to local conditions,
CANoe operated on a laptop proves to be an ef ficient mobile
diagnostic and measurement laboratory.
Comprehensive vehicle diagnostics on a display

screen
The vehicle can be fully parameter ized at any time via a pro-
7/12
13:09 Uhr
Seite 8/12
gramming PC that is connected to the CAN diagnostic connector. For every PistenBully there is an electronic vehicle
record that seamlessly documents software updates, the life
of individual components, current software levels, etc. It is
possible to restore the delivered state at any time. If problems occur at the customer, On-Board Diagnostics of fers fast
and convenient fault localization over the cockpit display. All
hydraulic functions, sensors and actuators are designed to
be electronically diagnosable. All that is needed for in-vehicle troubleshooting is a circuit diagram and the display; no
other equipment is needed. Stored in the fault memory are
the error history and error frequencies.
All figures: Kssbohrer Gelndefahrzeug AG
Authors:
Thomas Bck (Graduate Engineer) studied general
electrical engineer ing at the technical college in
Kempten, Germany. He manages development in
the electronics/hydraulics area.
Tel. 07392/900-254, Fax 07392/900-259,
E-mail: thomas.boeck@pistenbully.com
Peter Betz (Graduate Engineer) studied telecommunication engineer ing at the technical college in
Ulm, Germany. He is responsible for system development in the electronics development area.
Tel. 07392/900-262, Fax 07392/900-259,
E-mail: peter.betz@pistenbully.com
Markus Hrmann (Graduate Engineer) studied telecommunication engineer ing at the technical college in Kempten, Germany. He manages test equipment construction in the electronics testing area.
Tel. 07392/900-250, Fax 07392/900-249,
E-mail: markus.hoermann@pistenbully.com
Lothar Felbinger (Graduate Engineer) studied
automation engineer ing at the technical college
in Reutlingen. Since then he has been working as
Key Account and Business Development Manager at
Vector Informatik GmbH for the Open Networking
product line.
Tel. 0711/80670-505, Fax 0711/80670-555,
E-mail: lothar.felbinger@vector-informatik.de
09.02.2010
13:09 Uhr
Seite 8/13
7/13
Current Trends in Network Development for

Heavy-Duty Vehicles
Factors of success in electronic development
ECU networking in heavy-duty vehicles is characterized by the same challenges as in the automobile. Added difficulties are
caused by the large numbers of variants with low production volumes and longer product life cycles, requiring a suitable
architecture layout. Specially modified development methods are indispensable in handling cost pressure and sending reliable vehicles onto the street.
The number of ECUs, and hence the amount of software, has multiplied since electronification began in the early 1990s. While this
primarily related to the engine controller at the beginning, a large
number of electronic helpers are being implemented today.
Examples include ABS, ESP, ACC and other driver assistance systems
that make highway traffic safer and driving more pleasant. Analyses [1] assume that their implementation will increase further, and
that electronic control modules will account for 90% of all innovations by the year 2010. A key aspect is that 80% of these innovations will exclusively involve software or the functions implemented
in software. In this context, it is clear that software development
methods play a crucial role in the development process for the total
vehicle, and they have a significant influence on a vehicles success
or failure on the market.
Compared to automobiles, heavy-duty vehicle manufacturers are

confronted by the special challenges of the relatively large number
of variants with significantly lower volumes. Although simultaneous use of electronic ECUs over different brands and integration of
standardized components can reduce cost pressure, they make the
design of electronics and software more complex.
Flexible solutions are in demand

When one considers the variety of strategies used by different
heavy-duty vehicle manufacturers, it quickly becomes clear that
there is no universal solution. However, from a birds eye perspective clear trends can be seen, such as the use of standards, code
generators and a universal tool chain. The number of ECUs is
7/14
09.02.2010 13:26:23 Uhr
increasing at a rather moderate rate, while the number of functions

implemented purely in software continues to grow rapidly.
Common to solution strategies is the use of a comprehensive and
universal tool chain from requirements to validation. The use of
individual, non-coordinated tools proved to be impractical in the
past. The configuration processes and work results of individual
tools are too different. This makes it difficult to achieve universality of change requirements during development. Thus, a change
would need to be made in different tool configurations without any
automatic, inter-tool consistency check. This causes organizational
friction losses, especially in inter-departmental or inter-site development projects.
Therefore, a database with authoring tools should stand at the
center of the tool chain. Both the database and authoring tools
need to be specifically adapted to the requirements of the specific
vehicle manufacturer. Besides purely technical aspects, the tools
also take the individual development process of the companies into
account. Variants management, configuration management and
even the maintenance of workflows are represented in the tools. If
external suppliers need to be integrated in processes, the data
exchange formats that are used may be standards or de-facto
industry standards such as the CANdb++ data format by Vector
Informatik. In some cases, the vehicle manufacturer also prescribes
the use of certain tools to its suppliers. They are then tightly coupled to the database and support the supplier especially in such
aspects as compatibility to requirements, quality and efficiency.
Examples would be code generators for embedded systems or test
tools such as the CANoe.J1939 development and test tool from
Vector.
System design is becoming increasingly complex due to growing
requirements for networking. Individual ECUs are being installed
on different platforms and different countries, which increases the
number of variants. This requires flexibility in communication
structures and in mapping functions to ECUs. This not only affects
the available signals, but also the use of communication protocols.

In Europe, for example, proprietary communication protocols are
often used, which is similar to the situation in the automotive
industry there. In the North American market, however, the SAE
J1939 protocol dominates for heavy trucks. There are also differences in the area of in-vehicle diagnostics: In Europe, OBD diagnostics is implemented per UDS (ISO15765), and in the USA per SAE
J1939-73.
Attaining the goal by different approaches

The approach at MAN Nutzfahrzeuge AG is based on use of an integrated development database known as the Common Engineering
Data Backbone. All vehicle-specific functions are developed from
this platform, and all vehicle-specific information is stored there.
The eASEE Tool Suite from Vector with its 8 domains serves as a
universal development database, and it was specially adapted to
requirements at MAN in the framework of a configuration process
(Figure 1). It serves the needs of functional development and as a
description of the communication matrix. Since MAN relies on the
SAE J1939 standard as much as possible in communication, eASEE
was adapted to the requirements of the J1939 protocol.
A special module that was developed for MAN and adapted to the
Data Backbone serves as a bridge between modeling in eASEE and
automatic code generation for the ECUs (Figure 2). In code generation, the Munich-based heavy-duty vehicle producer relies on
proven CANbedded.J1939 standard software components from
Vector. CANbedded.J1939 gets all of the information it needs for
configuration and code generation directly from the database, and
it can generate the embedded code without manual interventions.
This enables immediate transfer of changes made in modeling to
the ECU code. This process prevents errors such as incorrect configuration of the code generating tool and guarantees error-free and
complete code generation. This process also simplifies verification
Figure 1:
The MAN Common
Engineering Data
Backbone
7/15
09.02.2010 13:26:24 Uhr
of the total system, since sections of the software have already

been checked. It is possible to reuse the communication data for
analysis tools like CANalyzer.J1939 or test tools like CANoe.J1939
from Vector, supporting the development of application layers.
The Volvo Truck Corporation chose a strategy for software development that has now become established in the automotive industry too: the use of AUTOSAR and its overlying tools (Figure 3). The
benefits of this approach lie in the use of standardized and proven
tools. They offer benefits in a development used intensively across
brands that is distributed among many business sites. Common
understanding of the underlying software structures and architecture is quickly achieved. It is easier to integrate suppliers, and it is
not absolutely necessary to specify tools. This reduces dependencies on individual tool producers and suppliers.
Problematic in this approach is the use of communication methods that are either incompatible with AUTOSAR properties or can
only be used with it in a proprietary way. The use of J1939, in particular, should be mentioned in this context. While AUTOSAR essentially assumes a network of known nodes and therefore a communication matrix that is known at the time of integration this is
decidedly not the case for J1939 with its plug-and-play concept.
Volvo Trucks confronted this challenge with a two-prong approach.
The first step was to identify which parts of J1939 were used in
Volvo vehicles and integrate them in the existing Vector AUTOSAR
tool chain. Secondly, Volvo together with Vector and other European heavy-duty vehicle manufacturers adopted portions of the
J1939 protocol in AUTOSAR. This strategy lets Volvo exploit the
advantages of AUTOSAR directly and universally. On the other hand,
AUTOSAR integration of J1939 makes it possible to achieve fundamental independence in tool selection. Volvo chose Vector as its
supplier of tools and embedded software components, since Vector
already offers solutions in all areas, and it was possible to adapt
them to Volvo-specific requirements very flexibly.
[1] J. Svensson, The Use of AUTOSAR in Volvo Group, presentation at
Vector J1939 User Day; slides may be downloaded at:
www.vector-informatik.de/j1939ud [most of them are German]
Peter Fellmeth
is a team leader and product manager at
Vector Informatik GmbH, where he is responsible for the development of products and
customer-specific projects related to J1939,
ISOBUS, Ethernet and DeviceNet.
Figure 2:
Code for the ECUs
is generated based
on the description
of the electronic
structure in
eASEEs functional
data management.
Figure 3:
When standardized data formats
are chosen,
standard products
can be used to
describe and
create the ECUspecific software.
7/16
09.02.2010 13:26:24 Uhr
SOLUTIONS FOR
Commercial Vehicles
The reliable, efficient way

to design and test networks
.J1939
.J1587
.CANopen
Development processes for open networks in commercial vehicles

can be implemented in the most cost-effective approach with
minimal time using specialized assistance:
> Develop your network design in a systematic approach using
reliable tools
> Successfully implement software components for both
proprietary and standardized J1939, CANopen and
AUTOSAR protocols
> Benefit from efficient configuration and extensive
diagnostic, testing and analysis solutions
The seamless interaction of Vector tools and Vectors comprehensive services will improve the efficiency of your entire
development process, from design to analysis.
Information and Downloads: www.j1939-solutions.com
sting
ce Te
E
r man
r ts SA
p
Confo
p
u o
939 s
ests
T
1
J
e
.
c
e
an
CANo
ompli
-82 C
J1939

70499 Stuttgart
Tel. +49 7 11 8 06 70-0
www.vector.com
09.02.2010 13:26:25 Uhr
Automatic Interoperability Tests for ISO11783 Systems

Universal test solution assures compatibility
The required unlimited compatibility of components on the ISOBUS cannot be attained by performing conformity tests at
the end of device development alone. Rather, sound and continual tests over the entire development phase are necessary.
Efficient use of such tests can only be achieved by using tools with domain knowledge that cover a large number of tasks
ranging from simulation to analysis tests as well as conformity tests. Developers of implements and tractors need a tool
that covers conformity testing, cycles through the tests independently, yet offer the freedom to only test certain sections
and can be extended to test the application.
In the agricultural machinery field, the information age has long
taken hold, and system thinking has replaced insular solutions. As
a result, a uniform data interface for interconnecting the tractor,
implements and on-board computer has become indispensable in
agricultural equipment. In this context, the internationally coordinated bus system ISOBUS was developed and introduced for the
first time at the 2001 Agritechnica fair. ISOBUS standardizes data
communication between tractor, implements and farm management computers and enables system-wide data exchange. The
ISO11783 series of standards consists of 14 sub-standards; they
each address different aspects of the technology, ranging from System Description (Part 1), Physical Layer (Part 2), Data Link Layer
(Part 3), Network Layer (Part 4) and Virtual Terminal (Part 6), Diagnostics (Part 12) and File Server (Part 13).
One persons pleasure is anothers pain is common folk wisdom. The situation is similar with the requirement for unlimited
compatibility (system and manufacturer independent) of ISO11783compatible products [1]. For the customer this is not only very easy
to handle, it also opens up the possibility of purchasing flexibility
and independence from the manufacturer. That in itself is a large
motivational factor in procuring such machinery. For manufacturers, however, this promise represents a great challenge in terms of
development, operation and maintenance of the machines. CANoe.
ISO11783 from Vector offers a universal development and testing
solution here. Option ISO11783 for the CANoe tool provides the
necessary domain knowledge and supports conformity to the
ISO11783 standard (Figure 1).
Experience over the past two years in the ISOBUS field has shown
that despite a sharply rising number of devices certified by conformity tests [2], different components, such as the Task Controller
and implement, do not always harmonize in their interaction without problems. There is the potential for surprises in operation of an
7/18
09.02.2010 13:28:34 Uhr
implement when the Virtual Terminal is used too. As well as for service technicians, in such a heterogeneous environment as the
ISOBUS it is difficult to definitively localize the cause of a problem
and correct it if necessary. Frequently, the technician is confronted
with unfamiliar devices or combinations of devices. In view of these
problems, and to assure customer satisfaction, the manufacturers
initiative AEF (Agricultural Industry Electronics Foundation) set up
a project group tasked with conducting activities to improve the
interoperability of ISOBUS devices [3].
Uniform diagnostic access for the worst case

In the framework of standardization tasks, along with continual
efforts to refine and extend test cases of the conformity test, Part
12 of the ISO11783 draft standard [4] was written to create a common diagnostic interface. It is based on SAE J1939-73 diagnostics
[5]. The section of Part 12 of the ISO standard that has already
been published, what is referred to as basic diagnostics, defines
open diagnostic access. It provides basic functionalities and is
intended to enable a system overview. This includes unique identification of the ECUs on the bus as well as information on the software version, manufacturers part number and the conformity test
performed. Each ECU can report momentary errors, and when
requested by the diagnostic tool it can also report previous errors.
This information is intended to enable quick and reliable localization of the error causes. This is especially advantageous if a network consists of components from different manufacturers. For
example, the tractor manufacturers service technician can use an
ISO11783-12 compatible diagnostic tool to detect problems related

to an implement from a different manufacturer. The technician
might not be able to correct the problem, but can clearly identify
its cause. If the cause lies in the implement, the tractor manufacturers service technician who was summoned by mistake can
call up valuable information such as error codes or part numbers of
the affected components to give the implement manufacturers
service technician advance information on the problem. This keeps
downtimes to a minimum and leads to a higher level of customer
acceptance of ISOBUS-equipped machinery.
Ongoing efforts to extend Part 12 of the ISO11783 draft standard are taking the direction of a standardized description format
for diagnostics. This would let each manufacturer describe diagnostic contents individually for each ECU. A prepared diagnostic
application could use this description to diagnose the ECU regardless of which company manufactured it. The diagnostic description
file might be downloaded from the ECU itself or over the Internet.
Manufacturers with their own company-specific diagnostic tool
would integrate ISO11783 diagnostics into their existing tool. Manufacturers without their own custom tools could use future standardized diagnostic tools. One practical benefit is that a service
technician would have system-wide diagnostic capability with just
one tool. This enables efficient and reliable localization of the real
causes of errors and ideally to correct them right away.
Figure 1:
CANoe.ISO11783 can be used to utilize, analyze and simulate the complex
communication structures of the
ISOBUS standard easily and efficiently.
Shown here is simulation of the File
Server, two implements and the
Virtual Terminal.
7/19
09.02.2010 13:28:34 Uhr
Automated tests during the development phase

Introduction of uniform diagnostic access helps to quickly identify
a problem on-site and possibly replace the defective part. If there
is some incompatibility, however, the situation is generally very
different. Replacing the electronics does not offer any help, since
this does not correct the cause of the problem. In such a case, corrected ECU software would be necessary. However, it would take
time to produce and test this software. In addition, distribution of
the modified software is often costly, since devices must be
recalled from the field. Suitable preventive actions can be taken to
avoid such compatibility problems. One option is the conformity
test mentioned in the introduction. However, a disadvantage here
is that the application itself is not part of the test. The focus in
conformity testing is to test conformity to the standard. In addition, it is difficult or impossible to use the conformity test during
development, since 100 percent compatibility cannot be assumed
at the beginning of development. Often just point checks of a
certain aspect are desired, e.g. a check of the Transport Protocol.

Such tests conducted over the course of development are generally
performed very frequently, they have many alternative test
sequences, and they must be flexible in their configuration. Therefore, such tests should be designed for automation. If problems
occur during the test, extensive analytical capabilities are needed
as well.
One tool for all cases

CANoe.ISO11783 from Vector is a universal development and test
solution that is used to verify conformity to the ISO11783 standard,
providing the necessary domain knowledge [6]. The Virtual Terminal, for example, is a fixed component of CANoe (Figure 1). Diagnostic messages can be visualized using the Diagnostic Trouble
Code Monitor and Scanner. The integrated Test Feature Set makes it
possible to define frequently recurring tests and entire test
sequences. The test sequences can be easily defined by XML, for
Figure 2:
Phases of Test
creation and interfaces with the
CANoe.ISO11783
Test Feature Set:
from creating the
test sequence to
evaluating the
results.
Figure 3:
Used in tandem,
CANoe.ISO11783
and the Vector VT
System form a
Midsize HIL.
7/20
09.02.2010 13:28:35 Uhr
AUTOMATIC INTEROPERABILIT Y TESTS FOR ISO11783 SYSTEMS
example. Figure 2 shows a schematic representation of the Test

Feature Set. In such an environment, CANoe.ISO11783 may assume
the role of the test master and link to or drive other tools over various interfaces such as COM or .NET. It is also possible to integrate
CANoe.ISO11783 in an existing test environment via the same
interfaces. Because of its extensive simulation and analysis capabilities, its use is not limited to just testing or simulation of individual ECUs. The tool can simulate entire networks (simulation of
the remaining bus). For example, operation of an implement could
be simulated via a Task Controller or the Virtual Terminal. With the
help of Vector test hardware VT System, CANoe.ISO11783 also
directly drives real consumers such as actuator motors and an ECUs
outputs, or reads in sensors (Figure 3). CANoe.ISO11783 can be
used to utilize, analyze and simulate the complex communication
structures of the ISOBUS standard easily and efficiently. It is a
comprehensive, universal tool for verifying conformity over all
product phases: from development to operation and service of the
working machinery.
Peter Fellmeth
studied Computer Engineering at the University of Applied Sciences at Esslingen, Germany, specializing in Automation Technology.
He is a team leader and product manager at
Vector Informatik GmbH, where he is responsible for development of products and
customer-specific projects related to ISOBUS,
SAE J1939, Ethernet and DeviceNet.

[1] VDMA Professional Society for Agricultural Engineering: ISOBUS speaks
all languages. Just speak along with it.2005, pg. 2
[2] VDMA Professional Society for Agricultural Engineering: ISOBUS-conformant devices per the ISO 11783 standard, www.isobus.net/isobus_E
[3] www.aef-online.org/
[4] Society of Automotive Engineers: J1939
[5] International Organisation for Standardization: ISO/FDIS 11783-12,
ISO11898
[6] www.vector.com/isobus
7/21
09.02.2010 13:28:35 Uhr
Device
09.02.2010
13:13 Uhr
Seite 1
Wireless analysis in a multiprotocol CAN environment

Timo Lw and Andreas Nacke (both Bomag), Holger Heit and Hans-Werner Schaal (both Vector Informatik)
n developing electronics for modern construction equipment, a large

share can even be tested
and simulated meaningfully on test benches. In later development stages, on
the other hand, it is preferable to perform tests and
trial runs under real conditions at construction sites or
outdoor test sites. To avoid
distracting the operator in
the drivers cabin with test
equipment, a wireless interface has now been realized for the first time with
the CANoe and CANalyzer development and analysis tools from Vector Informatik. Electronics developers at Bomag GmbH now
use this interface to log the
communication on various
vehicle buses at a distance
and analyze it. Quality requirements in earthmoving
work and highway construction are continually growing
with a simultaneous rise in
cost and time pressure. Soil
compaction and cost-, raw
material- and energy-saving methods of road preservation and reconstruction
are often only possible with
intensive use of high-tech
electronic functions. Bomag
is the global market leader
in the field of compaction
technology. At its lead-plant
in Boppard, this company
part of the Fayat Group
produces about 30 000 machines annually for soil, asphalt and garbage compaction as well as stabilizers/
recyclers. Today, a large
share of the companys expertise has its foundation in
electronics.
When it comes to networking technology, Bomag
7/22
66
machine with the most extensive electronics system

and the most CAN nodes.
First, it is used to improve
and reinforce existing soil
materials by mixing in lime,
fly ash or cement, and secondly for milling, pulverizing
and recycling existing materials in-place and locally.
Network cluster with

multiple CAN buses
Fig. 1: The electronics on the MPH 125 support efficient

implementation in soil stabilization and recycling
bases its work on the CAN
bus standards of the automotive industry. Initially, the
electronics concept was established on the large 10-t
to 15-t machines, and it was
then ported to the smaller machines. Since Bomag
would like to have hardware
and software components
be reused as often as possible within the overall corporate group, the focus was
on a modular concept. This
also required standardization of development and
test equipment across their
business sites.
enables satellite-supported, large-scale compaction

monitoring with seamless
documentation of all parameters. In the future, radio networks will provide for
data exchange between the
machines driving in a group.
The new type MPH 125 stabilizer/recycler with an operating weight of 24.5 t and
a power of 440 kW is the
All Bomag machines of a

given product line have the
same control system, and
they acquire their specific control functionality in
end-of-line parameterization. Therefore, electronic developers mapped the
machines modular product
concept to a modular CANbased network cluster. CAN
1 as the central BodyCAN bus is connected
to the most bus nodes. Its
operation is based on the
CANopen protocol, which
enables the use of standard
Nothing works
without electronics
High-tech equipment and
electronics can be found everywhere in the machines,
from remote controls to
drive-by-wire steering systems to the use of GPS.
Sensors continually acquire
the soil composition, and
the display graphically indicates to the driver where
compacting work is still
needed. The GPS option
Fig. 2: The electronics concept reflects the modular layout of the machines
CAN Newsletter 2/2008
09.02.2010
13:13 Uhr
Seite 2
Fig. 3: J1939-specific interpretation of data in the Trace Window is performed with CANalyzer.J1939
automation
components.
Besides the vehicles main
computer, the data acquisition unit of the front frame
and I/O module of the rear
frame, CAN 1 nodes also
include control and display
components in the cockpit.
Conventional analog and
digital sensors are interfaced to the data acquisition
unit, e.g. hydraulic pressure
sensors and fill level sensors. The I/O module on the
rear frame is responsible
for control of the variableheight rotor, lateral tilt angle
and lowering cabin feature
for transport purposes. It
was possible to significantly reduce wiring cost and effort by interfacing controls
to the bus; these include
the CAN-bus-capable joysticks, LC displays and external switches. Bomag created an in-house development of a CANopen driving
lever with friction brake.
The powertrain bus is
defined as CAN 2, and it interconnects the vehicles
main computer, engine controller, steering and driving
levers, including operator
consoles on the right and
left. Interesting here is that
the J1939 and CANopen
protocols are implemented in parallel on CAN 2. A
special feature of the drive
control system is load-limit control of the Deutz diesel drive, which provides
for dynamic power distribution between higher milling power at low speed and
lower milling power at high
working speed as a function
of soil composition.
Besides CAN 1 and
CAN 2 there may be a third
CAN 3 data bus, depending on how the MPH 125 is

equipped. It incorporates an
optional metering computer with auxiliary display and
the necessary actuators for
water injection. Similarly,
CAN 3 is needed to interface to the metering system
for bitumen emulsion and
foamed bitumen.
Multi-protocol
capable tools
In electronics development, Bomag implements
a number of software tools
from Vector Informatik. The
Stuttgart-based networking
specialist offers tailor-made
tools for all electronic development tasks, such as CANoe for network development and ECU tests, CANalyzer for analysis of bus data
and CANape for calibrating
ECUs. At the beginning of
development, CANoe simulates the behavior of individual bus nodes or entire
sub-networks (rest-of-bus
simulation). Over the further course of ECU development, the models serve
as a foundation for analysis, testing and integration
of bus systems and ECUs.
The C-like programming
language CAPL and userdefined interfaces simplifies the users work. A special real-time configuration
significantly improved realtime capabilities even further, first by using separate
PCs for rest-of-bus simulation and test execution, and
second by graphic control/
evaluation; this yielded the
high performance of a component HIL tester.
67
7/23
The CANalyzer analysis tool offers numerous

functions for bus analysis.
They range from tracing the
bus data traffic to displaying signal values, performing statistical evaluations
of messages, busloads and
disturbances, and finally
targeted generation of specific bus disturbances.
CANape is used in
the calibration of electronic ECUs. All important variables and parameter sets
can be modified and visualized in real time. Helpful
in conjunction with the de-
09.02.2010
Besides
supporting
CAN, the tools also support
the LIN, FlexRay and MOST
buses as well as the higher
level protocols J1939, J1587,
NMEA2000, ISO11783 and
CANopen. In the case of
Bomag, CANape and the
CANalyzer/CANoe options
for J1939 and CANopen are
used. Protocol-specific extensions of the tools relieve
the user of the need for detailed training in the J1939
or CANopen protocol; this
avoids faulty interpretations
of CAN frames. Last but not
least, another important re-
13:13 Uhr
now made it possible to establish contact with the DUT

by an extension via a modified WLAN system. So the
transceiver cable between
PC and CAN bus is quasi
removed and replaced by
the radio pathway. Noteworthy here is the fact there are
no significant compromises with regard to accuracy or measurement requirements. In implementing the
extension, special attention
was given to satisfying requirements for correct timing in data transmission, low
latency times and time-syn-
Fig. 4: The extended WLAN tunnels the CAN messages, including time stamp, via a
TCP/IP interface, thereby enabling time-conformant representation of the data
velopment of GPS applications is CANape Option
GPS, which supplements
the system with visualization of the momentary vehicle positions on an electronic map.
The universality of
Vector tools is paying off
at Bomag by helping it to
master the complex challenges of working with multiple buses, and in particular the J1939/CANopen
multi-protocol environment.
The consistently applied
database concept is an important pillar for the efficiency of the development
tools. All members of the
tool chain access the same
data set, so that it is possible to save all data consistently without unnecessary
redundancies or sources of
error. Fitting for the bus systems used, the relevant databases of the network description are either already
integrated or automatically
generated to match the network configuration.
7/24
68
quirement in the analysis of

muli-bus/multi-protocol environments is that a uniform
time base must always be
present as a foundation for
analyses.
No need for an
umbilical cord
What has been difficult for
Bomag electronics developers to achieve until now
is time-synchronous analysis of the measurement
data during the field tests
mentioned in the introduction without having to be
passengers in the machine.
They were only able to examine the logged data afterwards, but not during a test.
For these and similar cases, there is now a technically mature WLAN solution
from Vector: While previously it was absolutely necessary to maintain physical
contact to the bus system
being analyzed when working with the tools, the specialists from Stuttgart have
chronous display of the data

on the PC. The CAN messages together with their
time stamps are tunneled
via a TCP/IP connection, so
that the time stamps provided with the messages can
serve as reference times for
CANoe and CANalyzer.
Drilled out WLAN

solution
This solution offers some
key advantages compared
to the capabilities of a simple CAN/WLAN bridge.
Only a bridge header is necessary for this setup. Sufficient as a host is
a WLAN-capable laptop/
notebook, which maintains
the connection via standard on-board resources
and WLAN. The probe on
the DUT that is responsible
for converting from CAN to
WLAN sends the messages
in strict and chronologicallycorrect order by considering
the time stamps originally
Seite 3
logged on the bus, which

would not be possible via
a CAN-WLAN-CAN bridge.
During machine operation
at the construction site, the
Bomag electronics developers can measure, observe
and evaluate without a hard
wire connection to the machine.
Summary and
outlook
This example from the commercial vehicle sector shows
that there are interesting
and demanding challenges
outside of the realm of automotive electronics for luxury cars, challenges that can
only be handled by complex network clusters and
high-performance
development and analysis tools.
The universality of Vector
solutions pays off here. The
tools enable analyses and
simulations directly on the
higher layers of J1939 and
CANopen. The use of multiple buses or simultaneous
use of different protocols on
the same bus do not present any problems. The tools
always ensure correct timing with the same time base
in data acquisition and evaluation even in the case
of wireless communication.
The Bomag developers already have their sights set
on the next WLAN project
involving automatic, multiday durability tests. Thanks
to a WLAN connection, the
electronics developers are
able to continually observe
events on the relevant bus
systems with the mentioned
tools. That can be done
from the office or via the Internet, e.g. from home during the weekend.
Sources: Fig.1 and 2: Bomag
GmbH, Fig. 3 and 4: Vector Informatik GmbH
holger.heit@
vector-informatik.de
timo.loew@bomag.com
andreas.nacke@
bomag.com
hans-werner.schaal@
09.02.2010
13:13 Uhr
Seite 4
7/25
Moving Communication
Wireless Analysis of In-Vehicle Networks
In the future, data communications in the automobile will also take place beyond the vehicles boundaries. New requirements are evolving, especially in the development of applications such as Car2x and remote diagnostics. These challenges
are best solved with relevant tool support, where CAN messages are tunneled via the wireless air interface.
Modern driver assistance systems are indeed capable of looking
into the distance, but only with sensors (Radar, Lidar, ultrasonic,
cameras, infrared, etc.) installed on-board the vehicle. Their ranges, and consequently their prediction abilities, are limited. In
efforts to prevent hazardous driving situations and optimize traffic
flow, it is considerably more promising to evaluate information
from other traffic participants as well. Communication with the
external environment is necessary to utilize measured values from
external sensors. This takes other vehicles into consideration (Car2Car communication) as well as stationary systems known as roadside units, e.g. at traffic lights or tunnel entrances (Car2Infrastructure communication). The applications are extremely diverse,
ranging from warnings of traffic jams around a curve with restricted
visibility to the transport of current information related to driving
route optimization or parking situations. The required transmission
technologies such as WLAN and pWLAN are already available.
Figure 1:
The electronics in the MPH 125 support its efficient use in soil stabilization and recycling.
7/26
09.02.2010 13:28:47 Uhr
While the advantages sound promising for all traffic participants, the challenges for developers are great too. Although the
developer had extensive capabilities for analyzing a vehicles various data networks and their interactions with one another, today
the developer is faced with the dilemma of not being able to sit in
two or more vehicles simultaneously.
Wide-ranging applications
Besides its use in the development of future driver assistance systems, there are many other application areas for wireless analysis
of bus systems. A typical example would be the testing of agricultural and construction equipment. With the enormous growth in
functionality and automation, CAN-based bus systems have already
made in-roads in these fields for a long time now. The problem
often encountered here is that the developer cannot ride aboard
the equipment during field trials under real operating conditions.
In stationary networked systems as well, especially in the area of
factory automation, there are bus systems that are difficult to
access (due to heat, gases, etc.) and whose analysis is simplified
or even made possible by a wireless interface.
The following example, a real application in the development of
construction machines, shows that today there are already solutions that can fulfill current Car2x and remote diagnostic
requirements.
Wireless analysis of modern construction equipment

In the electronic development of modern construction equipment,
it makes sense to conduct a large share of testing and simulation
on test benches. In the advanced development stage, however, it is
preferable to conduct testing and trial runs under real conditions
at construction or test sites. In a joint project with Vector, electronic developers at BOMAG GmbH implemented a wireless interface to the development and analysis tools CANoe and CANalyzer.
This allowed developers to log communications of the various vehicle buses remotely and analyze them.
BOMAG, the global market leader in the field of compaction technology, bases its networking technology on the CAN bus standards
of the automotive industry. High-tech equipment and electronics
can be found everywhere in the machines, from remote controls to
drive-by-wire steering systems and the use of GPS. The new stabilizer/recycler model MPH 125, with an operating weight of 24.5
metric tons and power output of 440 kW, is the machine with the
most extensive electronic systems and the most CAN nodes. On the
one hand the machine serves to improve and stabilize existing soil
materials by mixing in lime, fly ash or cement. On the other hand it
is used to mill, shred and recycle existing local and on-site materials (Figure 1).
Figure 2:
The electronics concept addresses
the modular structure of the
machines to integrate customerrequested options: metering computers, water injection, bitumen
emulsion or foamed bitumen.
7/27
09.02.2010 13:28:48 Uhr
Figure 3:
The WLAN extension tunnels
the CAN messages along with
their time stamps via a TCP/
IP connection, which enables
time-conformant display of
the data on a PC. As a result,
the user experiences hardly
any of the limitations of
hard-wire communication.
Network cluster with multiple CAN buses

Electronic developers have modeled the product concept as a modular CAN-based network cluster (Figure 2). CAN 1 as the central
CAN Body Bus is connected to the most bus nodes and operates
under the CANopen protocol, which enables the use of standard
automation components. The Powertrain Bus is defined as CAN 2
and combines the main vehicle computer, engine controller, steering and driving control levers, including user control consoles on
the left and right. In CAN 2, the J1939 and CANopen protocols are
used in parallel. Depending on how the MPH 125 is configured,
there may be a third CAN 3 data bus as well (Figure 2).
Without umbilical cord: Wireless field tests now

possible
Previously, it was difficult for BOMAG electronic developers to conduct time-synchronous analysis of measurement data during the
field tests mentioned in the introduction, without having to ride
along in the machine. They were only able to examine the logged
data afterwards, but not during a test. For these and similar cases,
there is now a technically mature WLAN solution from Vector. While
previously it was absolutely necessary to maintain physical contact
between the tools and the bus system being analyzed for this work,
the specialists from Stuttgart have now made it possible to establish contact with the device under test (DUT) via WLAN by adding a
tool extension.
In implementing the extension, special attention was given to
satisfying requirements for correct timing in data transmission, low
latency times and time-synchronous display of the data on the PC.
The CAN messages together with their time stamps are tunneled
Figure 4: Panels in
CANoe.IP helps to
visualize signals.
Signals are displayed in the Data
and Graphic windows, while analysis of the Ethernet
protocol and signal
decoding appear
in the Trace
Window.
7/28
09.02.2010 13:28:48 Uhr
MOVING COMMUNICATION
via a TCP/IP connection, so that the time stamps provided with the
messages can serve as reference times for CANoe and CANalyzer
(Figure 3).
Frank Weber
is Product Management Engineer for the Open Networking product
line at Vector Informatik GmbH.
Extended WLAN solution has advantages
Hans-Werner Schaal
is Business Development Manager for the Open Networking product
line at Vector Informatik GmbH.
This solution offers some key advantages compared to the capabilities of a simple CAN/WLAN bridge. Only one bridge head is necessary in this setup. Sufficient as a host is a WLAN-capable laptop/
notebook, which maintains the connection via standard on-board
resources and WLAN. The probe on the DUT responsible for the
CAN-on-WLAN conversion sends the messages in strict and correct
chronologically order by evaluating the time stamp originally
logged on the bus; this would not be possible via a CAN-WLAN-CAN
bridge. During machine operation at the construction site, BOMAG
electronic developers can measure, observe and evaluate without a
hard-wire connection to the machine.
Development, simulation and testing of embedded

systems
Vector now offers Option IP for the simulation, testing and analysis
tools CANoe and CANalyzer to provide a wireless interface to a CAN
bus system (Figure 4). As in the example described above, it is now
possible to analyze CAN bus systems with the help of a CAN-WLAN
gateway and a test computer connected via WLAN. CAN-based
J1939 and CANopen protocol extensions to CANoe and CANalyzer
are supported as are extensions for ISO11783, NMEA2000 and
DeviceNet. It is also possible to analyze CAN bus systems on spatially separated vehicles, which is necessary for the development of
future driver assistance systems in the framework of Car2x. In this
case a common time base is established by CANoe/CANalyzer.IP to
synchronize the probes on the different vehicles. If an overabundance of data makes the bandwidth of the WLAN connection too
narrow, the CAN-WLAN gateway can be replaced by a second test
computer with CANoe.IP. It is then possible to perform filtering or
preprocessing of the data on that computer to limit the actually
transmitted information to what is essential.
Besides facilitating wireless transmission of CAN messages,
CANoe.IP and CANalyzer.IP also enable the analysis of Ethernetbased networks, sending of Ethernet packets and simulation of
gateways between Ethernet and CAN.
7/29
09.02.2010 13:28:49 Uhr
Prototyping and Testing CANopen Systems

Reaching goals rapidly with minimal effort
CANopen established itself as a standard for cost-effective and flexible networking of components in numerous application
fields ranging from industrial automation to commercial vehicles. Standardized device profiles simplify communication
between bus nodes and facilitate smooth interplay between the ECUs, sensors and actuators from different manufacturers.
A specialized prototyping and test tool not only performs valuable services in developing complex CANopen projects, but
also in providing a fundamental introduction to the subject area.
The bandwidth of tasks in the development of CANopen systems
ranges from developing individual ECUs to configuring and starting
up total systems. For system producers, the initial use of a system
such as CANopen is associated with an incalculable startup effort.
In the framework of the V-model, a large share of development
tasks involves verification and validation. The risk of detecting
errors too late is minimized by comprehensive tests at the earliest
possible time (Figure 1).
process during the test phase, since generally only one test setup
is available.
A way out of this dilemma might be offered by a software tool
that could be used to create a prototype of the future total system
in a simple way. Optimally, this tool would also offer extensive test
functions.
System verification with test setups
Above all, prototypes of total systems networked by CAN should

support testing and validation activities. In addition, it is important to represent the individual components by real or simulated
ECUs. This makes it relatively easy to test the functional capabilities
of real ECUs over the course of system development.
Creating a prototype for a complex total system is a complicated
endeavor in which it pays to use suitable tools. CANoe.CANopen
from Vector offers valuable assistance in creating communication
for the prototype system. In just a few configuration steps, it lets
the user create a prototype whose communication properties match
those of the later real system.
The behavior of the CANopen ECUs is defined in description files
(EDS Electronic Data Sheet) that are selected or created
Systematic tests accompanying the development of a total system

are indispensible in all development steps. Often it is possible to
test, but not until a very late time, when actual system components
are available. Then, the system completion date is at risk if problems occur.
In practice, tests are not performed on the real system at the
customers facilities, rather test setups are used for this purpose.
Besides special measurement or diagnostic setups, in testing they
also include actuators for simulating system environments as realistically as possible. Depending on the project size, such a test setup could incur much cost and effort. Bottlenecks are built into the
Creating a prototype environment with tool support
Figure 1:
Representation of
the V-model
7/30
09.02.2010 13:25:05 Uhr
beforehand. This next step is to define the interrelationships

between calibration data that will later be exchanged over the bus,
e.g. the PressureValve input of the device with address 5 (pressure transducer) is linked to the Gas pressure variable of the
device with address 10 (control module). This is how all PDO (Process Data Object) interrelationships are defined in the prototype
system.
The tool automatically computes the resulting mapping, which
can be modified later if necessary. From this configuration information (DCF Device Configuration File) the user now generates
the prototyping environment, i.e. CANoe generates a counterpart
for each real ECU with identical communication properties. When
CANoe is started, the communications portion of the prototyping
environment is already available (Figure 2).
Defining application behavior

The application behavior of individual ECU nodes cannot be derived
directly from the EDS files, since they only map the structure of an
object directory. Therefore, formulation of application behavior
always involves additional programming effort. The CAPL programming language integrated in CANoe makes it possible to program
ECU behavior quickly. As an alternative it is possible to code ECU
behavior in a DLL that is linked in the prototyping environment
under CANoe. It is also easy to integrate Matlab/Simulink models
(Figure 3).
Test functionality
After the prototype system has been completed, the necessary
tests for the total project follow. CANoe supports the user here,
both in creating tests and in logging and evaluation. The test functionality required for a CANopen system comprises several stages
(Figure 4):
> Protocol level:
Tests on this level ensure that CANopen-specific communication
protocols of the individual devices are implemented within the
total system according to specification.
> Communication level:
> What is important here is not the correctness of the protocol, but
the correct logical order of (independent) protocol sequences,
e.g. in configuring PDOs. Description of the PDO-relevant entries
in the object directory must conform to a specific sequence.
> Application level:
Application tests check the relationships between process
variables. The following preconditions must be met to even
determine such relationships: First, the process variables must
be exchanged via PDOs, and the system must be fully configured.
This means, for example, that the state of a valve can be checked
as a function of a temperature or a pressure. Clearly, the user
must have the relevant know-how to formulate the test.
Figure 2:
Sample configuration of a simple,
simulated CANopen network with
central control and I/O node
7/31
09.02.2010 13:25:05 Uhr
Creating and executing test procedures with CANoe
Summary
Test sequences are formulated under CANoe with the help of the
integrated CAPL programming language. Each CAPL test module
represents a separate test consisting of individual test cases, which
in turn contain a number of test steps. During the test run, CANoe
processes the individual test cases sequentially. Suitable test flow
control makes it possible to skip or repeat individual tests. Simultaneously, it is possible to monitor conformance to other conditions
and restrictions quasi in background. This might be done, for
example, to determine while waiting for a specific message of
interest whether a specific other message is sent periodically on
the bus.
Especially in automated tests, it is important to record the
results of individual test steps in detail. Other CAPL functions handle writing of test results to an XML file for later post-processing.
Test sequences for CANoe can also be specified under XML. This is
advantageous when a large number of test flows need to be generated with a single tool. So CANoe utilizes a number of test patterns
specified in XML and processes them accordingly.
When prototypes are created in CANopen networked systems, this

process always involves considerable effort. Yet the process is often
essential to prevent findings on functionality from being delayed
until a later project phase. Special tools such as CANoe.CANopen
offer the user efficient support in creating prototypes. The requirements for technical aspects of communication, in particular, are
very easy to cover in this way. In every phase of a project, this gives
the system developer the test functionality needed to check and
verify components completed up to that point in time.
Figure 3:
Representation of the CANoe.
CANopen environment
7/32
09.02.2010 13:25:05 Uhr
PROTOT YPING AND TESTING CANOPEN SYSTEMS
Mirko Tischer,
Product Manager for CANopen.
Figure 4:
Test levels in
CANopen
7/33
09.02.2010 13:25:06 Uhr
Tools
Automatic testing of
CANopen devices
Kai Schmidt (Vector Informatik)
he growing complexity
of todays system architectures is associated with
an increase in the effort
that must be invested in test
specification, test creation
and test execution during
the development of such
systems and system components. Test specifications
should be available in early
phases of the development
process, e.g. after the system architecture has been
created or during component design. This makes
it possible to detect errors
early and correct them costeffectively.
The development process for a CANopen system
can be described based
on the V-model. In the first
phase, system requirements
are defined, which for the
most part contain the definitions of individual use cases. This information represents the input for the next
step, where initial assessments can already be made
of the system architecture.
Functions are assigned to
Fig. 2: Device functionality
8
7/34
2
Fig. 1: Development process of a CANopen system

the individual ECUs, and
device descriptions can be
created for all devices in the
form of EDS files (the format of the EDS files was
standardized by CiA and is
being further developed by
this organization in cooperation with industry). In addition, communication relationships between the
ECUs can be configured,
as network management
and error detection mechanisms. EDS files describe
significant parts
of the functional scope of a
CANopen
device. These device descriptions
form the foundation for executing the simulation and creating
test specifications. Communication-specific
tests can be derived
directly
from the device
descriptions. An
example of this
would be a test
that checks all
objects in the object dictionary by SDO accesses and

records the results. Besides
c ommunication-specific
tests,
application-related
tests can also be specified.
An example of such a test
would be to stimulate the
transmission of the digital
input of an I/O device. Afterwards, a check is made
to verify that the signal value exists at the output. Both
tests could be used early in
the simulated overall system. As soon as the stability of the overall system
has been achieved, development of the individual
components can be subcontracted. The EDS files
can with the exception of
application-related behavior be considered as a requirements specification for
the supplier. Parallel development of the ECUs at the
suppliers is accompanied
by the simulated overall
system. Application-related
tests can also be utilized at
the supplier to test the behavior of the device to be
developed within the overall system. This can signifi-
cantly reduce the number of

cost-intensive changes desired by the OEMs which
generally occur within the
integration phase. Communication-specific tests can
be created at the supplier
in a similar way as at the
OEM.
After completion and
acceptance of the components, they are successively integrated into the simulated overall system. The
previously created communication and applicationrelated tests can now be
applied to the system, consisting of the physical components and the rest-of-bus
simulation. As soon as all of
the components have been
delivered the concluding
test of the real overall system follows.
EDS files as the

basis for tests
The development process
should include the creation
of an EDS file appropriate
to the device. Unfortunately, practice shows that device producers often ne-
09.02.2010 13:25:18 Uhr
Tools
glect this work step. Faulty

or incomplete EDS files are
the result; in the worst case
there is no EDS file at all for
a device. The development
process described above
shows that it is not just device producers who need to
be concerned with creation
of EDS files, but system designers too.
The task of the system
designer here is to distribute functionalities to the individual components. These
could be standardized functionalities such as mechanisms for process data
communication, but they
might also be manufacturer-specific functionalities.
Both of these are mapped
via objects in the object dictionary. CiA specifications
describe standardized functions. Standardized parameters (process data, configuration and diagnostic data)
as well as manufacturerspecific data can be stored
in a database format that is
also standardized. The necessary objects can be selected from the object pool
that is created in this way,
and be assembled into an
object dictionary.
The device descriptions contain all of the information necessary for
simulation of the CANopen
device. The overall system,
consisting of the individual
device descriptions, is parameterized utilizing a suit-
able configuration tool, and

an initial system description is obtained in the form
of device configuration files
(DCF), whose format has
also been standardized by
CiA. Based on this configuration, simulation models
can be generated and executed in a suitable runtime
environment. At an early
point in the project, this already enables conclusions
about the time behavior of
the overall system. If excessive bus loads occur, for example, actions can immediately be initiated to correct
the problem, since suppliers have not been involved
in the development process
yet. Accordingly, the simulated overall system offers
a high degree of flexibility.
It can be refined iteratively
until it satisfies the defined
requirements. Changes to
the simulated system can
be implemented cost-effectively and be checked immediately.
Derivation of test
sequences
Besides the simulation, it
is also possible to derive
initial tests on the protocol and communication levels from the device descriptions. The protocol test includes checking of the SDO
protocol, for example. The
communication tests do not
check for correctness of the
protocol, but instead for correct flow of message sequences. For example, it
is possible to test whether
the configuration sequence
for process data objects
conforms to the sequence
specified in CiA 301.
The following test templates
with general application can
be defined for a CANopen
device:
SDO download test
SDO upload test
Heartbeat producer test
Heartbeat consumer test
Transmit PDO test
EMCY test
Test functions are created
for each object contained in
the object dictionary here.
The test functions are parameterized based on the
data contained in the configuration files for the devices. Among other things, test
sequences can be generated to check the:
PDO configuration
Default values
Object dictionary
NMT state machine, and
SDO protocol
The generated tests may
be executed right away in
a suitable runtime environment. In the framework of
integration work, it is precisely such tests that are
used to check the delivered
components. In turn, suppliers can generate similar
test sequences to assist in
development. They can immediately be applied to the
prototypes. Essentially, this

is a way to generate test sequences of the conformance
test (CiA 310) device-specifically. However, the goal of
the system should not be
to replace the CiA conformance test altogether. The
system should accompany
the development and give
developers a way to test devices in advance of the actual tests. The final certification is only performed by
CiA.
Generation template
for each version
Generation templates must
be created for each test, but
they are applied to each device to be tested. A generation template that describes the creation of a test
for checking the object dictionary would appear as follows:
for all objects
{
get access type
if(access == read
only){
add test function
SDO Upload
to test sequence
} // if
else if (access ==
read write){
add test function
SDO Upload
to test sequence
add test function
SDO Download
to test sequence
} // else if
.
.
}
The generated test sequence created based on

this test template contains
a number of parameterized
(by entry of object index,
etc.) write and read routines. They are processed
sequentially in test execution.
Iterative development
process
Since iterative processes
are applied throughout a
devices development, the
Fig. 3: Test sequences of a CANopen system
10
7/35
09.02.2010 13:25:19 Uhr
process for generating test

sequences must be repeatable as often as needed.
Changes to the device design can affect the device
es receive or send them.

Among other things, precisely these aspects must
be tested. This subject matter can be explained by the
Fig. 4: GPS date object description

descriptions. The test that
was originally generated
would then likely fail. Nonetheless, it is still necessary
to be able to manually extend test sequences after
generation, e.g. to incorporate application-specific supplements. These extensions must be read back
when the sequence is regenerated.
Application-related
tests
The application-related behavior of the devices can
not be represented in the
device descriptions. Furthermore, the tester does
not want to have to deal with
the CANopen-specific conceptual world and its definitions on the application
level. On this level, it is entirely unimportant to know
which signal is mapped to
which object at which position. More important is information about which signals exist and which devic-
example of the CiA 447 application profile (application

profile for special-purpose
car add-on devices):
The
standard
defines an object GPS date.
Mapped to this object are
the signals GPS date year,
GPS date month and GPS
date day.
The CiA 447 profile,
besides defining signal allocations in the objects, also
defines the transmission
type. The standard specifies that the object value
GPS data is transmitted
by SDO protocol. The following information is needed to transmit a signal as
part of a test:
Index + Sub-Index of the
object
Signal length
Start position of signal
within the object
The format of todays EDS
files is unable to describe
the signal allocations of object values. Accordingly, information such as the signal
length and start position of
7/36
09.02.2010 13:25:19 Uhr
Tools
Fig. 5: Generated test environment
the signal is also unsupported. Even if these requirements could be implemented, it is not possible to automate generation of application-related test sequences, since the behavior of the
system is not described.
Generated test
environment
Nonetheless, the developer
can be supported by gener-
he Codix 538 display by

Kbler provides a CAN/
CANopen interface in order to display locally any
user-defined value. Numerical values can be directly
scaled using a factor or offset from the display device.
The display has a floating
decimal point that can be
inserted in any position. Via
the CAN network encoders can be read out directly, thanks to the Automatic
Operational Mode. The display is provides automatic bit-rate detection and up
to 16 node-IDs that can be
set via rotary switches. The
CAN port supports base
and extended frame formats with maximum datarate of 1 Mbit/s. The display comes equipped with
a 6-digit, 8-mm high-red 7segment LED. Each segment can be directly written to, allowing not only val-
12
ation of an interaction layer in test creation. If this extension can be integrated in

the simulated overall system, then it is easy to create application-related test
cases.
The test system consists of the simulated nodes
that are extended to include an interaction layer.
One or more physical devices are tested. The simulated devices are stimulat-
ed via generated interface

functions. Signal values
are mapped to object values and the CAN messages are sent. In the example
depicted, the signal value
GPS date month would
be mapped to the relevant
position in the object value
(startbit 16, length 4 bit).
Parameterization
of
the test functions assumes
that the positions and
length of the signals are
Display communicates with encoder

ues to be displayed but text
messages also. There will
always be room for the display, thanks to its DIN housing that measures 48 mm
x 24 mm, with an installation depth of just 59 mm.
Reverse polarity protection
likewise facilitates installation. On account of its high
IP65 protection rating the
display can be easily used
in industrial environments
without the need for an additional protective housing.
The company offers several encoders with CANopen
connectivity since many
years. The Sendix absolute
encoder features now an
additional incremental track.
Parallel to the CANopen
output this encoder outputs
an additional TTL compatible signal with 2048 puls-
es per revolution. As well

as the CANopen output, the
encoder is also fitted with
an RS-422 interface, which
outputs the signals A,/A,
B,/ B. This means it is possible to implement simultaneously both positioning via
the CAN network and direct feedback of the speed
all in just one encoder,
said Pierre Brucker, Marketing Director at Kbler. This
saves on the costs and installation space that a second encoder would have
entailed. Using the variable
PDO Mapping in the memory the user can decide,
which information is to be
available in real-time. Functions, such as the transmission of speed, acceleration
or exiting the work area,
ensure fast data availabil-
known. Moreover, the transmission type must be considered. This information

is described exclusively in
the standard and must be
considered in test creation.
Use of an interaction layer enables signal-oriented
test creation. It will be possible to define the function
Send_GPS_month
and
generate its implementation based on the CiA 447
specification, if it exists in
XML format in the future.
Todays format of the specification requires converting
the specification to a readable format (XML or Excel).
This conversion task
can be assumed by a generator. The generated functions contain a mapping of
the signal to the object value and a routine for sending
the CAN messages. During
test creation, the test engineer need not be concerned
about signal positions, indices or transmission types.
All the test engineer is interested in are the signal
name, sender, receiver and
signal value.
kai.schmidt@
ity while reducing the load

on the bus and controller.
The real-time position acquisition of the expanded CANopen Sync function
enables genuine time-synchronous position detection
of several axes. Kbler is
also lunching slip rings (ISTSR085 and IST-SR060) that
can be used to transmit
bus signals between a stationary and rotating platform. Typical applications
include cranes, rotary tables, etc. The transmission
between stator and rotor
units takes place via sliding contacts (for current up
to 40 A). Thanks to their fully encapsulated housing (in
high-grade glass-reinforced
plastic), high protection rating (up to IP 64) and resistance to vibration, these
rugged products are suited
to industrial use.
www.kuebler.com
7/37
09.02.2010 13:25:20 Uhr
09.02.2010
13:13 Uhr
Seite 1
Before consider ing tools it is essential to have a handle on t

Vector Consulting, with its eASEE product, is of fer ing a complete tool environment for managing and controlling engineer ing business processes. The software is capable of organizing all
of the processes and product data for software
and electronic systems over their entire product
life cycle. ATZ elektronik magazine spoke with
Dr. Thomas Beck, CEO of Vector Informatik and
Vector Consulting GmbH, about development
processes in developing automotive electronics
and about the advantages of eASEE (pronounced: easy).
Dr. Thomas Beck, CEO of Vector Infor matik GmbH and
Vector Consulting GmbH
ATZ elektronik: Dr. Beck, what are the typical issues that arise in the development process for automotive electronics?
Beck: First a distinction should be made between two subject
areas here. They are the engineer ing process on the one
hand, and the management process on the other.
The engineer ing process is concerned with master ing technical complexity, i.e. the interaction of electronic components
that are evolving into increasingly comprehensive systems,
e.g. driver assistance systems, ACC, lane keeping systems,
etc. These systems of fer great challenges to automotive
manufacturers.
In the context of management processes the primary concern is with planning and control of engineer ing, such as in
project planning and tracking. However, improved communication between producers and suppliers and the challenge of
continually bringing new products to market faster and more
ef ficiently are also requirements of the management process. When one examines the methods, processes and organizational forms with which the automotive industry has typically operated, the writing was already on the wall several
years ago: Manufacturers and suppliers had to improve their
system development capabilities enormously to even be able
to develop complex networked electronic systems and to
thereby remain competitive. If you look into large corporations today, you will see that extensive programs are being
started everywhere to improve development processes and
enhance quality.
8/0
ATZ elektronik: What does eASEE contribute in this context,

and how are development tools linked to it?
Beck: Vector has set up a team that works intensively in consultation services related to development processes. These
are specialists who together with customers, i.e. OEMs and
Tier-1 suppliers, analyze and optimize their development
processes. Before consider ing the tools to be used, it is necessary to have a handle on the process level first i.e. to understand and document it.
A tool like eASEE can help to firmly embed processes in the
organization in a lasting way. This protects investments
made in process improvement projects. eASEE supports all
technical processes in an organization, such as configuration management, change request management, project
management and product life cycle management. Our tool
handles all of an organizations data storage needs. To some
extent this makes eASEE a backbone that of fers cer tain functionalities, and engineer ing tools dock to this system. Examples of such tools are: Doors, our DaVinci tool, Ascet SD and
Matlab Simulink.
ATZ elektronik: What does the intelligence look like for linking these useful data that originate from very dif ferent sources?
Beck: eASEE has var ious modules: Engineer ing Data, Workflows, Process and Project Management and Strategic Project
Planning. This means that we also of fer Engineer ing-Data
Management. This module provides the necessary logic for
linking dif ferent documents and data. The documents are
embedded in a coherent corporate data structure, and rela-
09.02.2010
13:13 Uhr
Seite 2
n the processes first
tionships are established between them according to predefined processes. The questions addressed here are always
process-related. Supplemental logic is required for data that
are relevant to mechanical design. Such data are integrated
into the system in the form of customizing.
A data structure might represent a vehicle configuration for
a passenger car or heavy truck, for example. Data it contains
might belong to the Engine Management System, Gateway,
or Transmission System; in the specif ic control module these
data extend deeper into the software, into functionality, to
the CAN message level or to the model level, for example a
Matlab Simulink model. As an analogy, one might picture a
well-organized drawing cabinet containing all of the elements that make up the vehicle.
ATZ elektronik: How is eASEE implemented at your customers?
Beck: The prerequisite for meaningful use of such a product
is that the customer must have already defined its processes
internally. If that is not the case, the customer cannot even
start to use eASEE. In introducing the product to a company
it is unimpor tant whether we per form the service or another
consultation firm handles it. In principle, potential collaborative partners not only include large corporations like IBM,
but also small companies who are specialists in this area.
Once processes have been clearly defined, the product must
be customized to the processes. Vector already of fers prepared solutions here that can be adapted to a customers
needs.
ATZ elektronik: Sometimes it is not so simple to introduce
new processes. What has your experience been in this area?
Beck: In projects that we per formed recently, management
stood clearly behind process development. The bottom line
is that engineers too are upset when they cannot find documents or when cooperative work ef forts do not succeed. The
climate for processes has been transformed in recent years
based on this fact. Good organizational development means
addressing both sides. It must be a Win-Win situation for
management and engineers. To cite another example: At all
times the engineer has the oppor tunity to observe in eASEE,
the workflow process has taken to date as well as the current
status of the process. After all, the purpose of such a system

is to produce transparency. To use an example: eASEE is like
a corset that should be suppor tive but not restrictive.
ATZ elektronik: Lets take a recent example like AUTOSAR:
What role does eASEE play here?
Beck: AUTOSAR defines a great deal of information. Essentially you must dif ferentiate two levels: The base software,
CAN networking, LIN networking, etc. on the one hand, and
above these the so-called AUTOSAR software components
that specify how a function such as exterior lighting control
or interior lighting control must be described. It is precisely
this information that must be managed. The AUTOSAR data
backbone accomplishes this, in this case eASEE. By the way,
one of our next development goals is to of fer a standard environment that mirrors the AUTOSAR data model and development process. AUTOSAR takes the complexity of the development process to a yet higher level, making eASEE that
much more beneficial.
Author:
Dr. Thomas Beck finished his studies on Electrical Engineering in
1986; doctorate degree in 1992; began business career in var ious
positions at Bosch and ETAS; 19972000 CEO of the ETAS Group; and
since 2001 partner and CEO of Vector Informatik GmbH and Vector
Consulting GmbH
8/1
09.02.2010
13:06 Uhr
Seite 1
Tool-supported Data and Process Management

at MAN Nutzfahrzeuge AG
At MAN Nutzfahrzeuge AG an integrated approach
was applied to managing all engineer ing data
generated in the E/E development process and its
subprocesses. The goal is to fur ther improve the
ef ficiency and quality of development, despite
the growing complexity of electronic systems.
MAN Nutzfahrzeuge AG developed and introduced
an integrated development database for this purpose, which is based on the eASEE Tool Suite from
the Vector company:
The MAN Common Engineer ing Data Backbone.
1 Motivation and Goals

The development of vehicle functions, ECUs and ECU networks is becoming more and more complex. It is becoming increasingly impor tant for MAN Nutzfahrzeuge AG to be able to master this complexity
into the future. The primary objective is to increase development
ef ficiency while fur ther improving product quality.
2 Basic Ideas
Two factors led to the development of the MAN Common Engineer ing Data Backbone: First, it was clear to management very early on
that quality could not simply be achieved after wards by an extensive testing process. Rather a universal, well lived-out development
process is necessary, which encompasses all areas of development.
Second, management at MAN favored an integrated database solution that saves all data of the development process in a meta model
(single source) [Figure 1] and thereby enables very ef ficient data
usage and data universality. The ability to set relationships between data fur ther increases ef ficiency. This database solution is
referred to at MAN as the Common Engineer ing Data Backbone.
3 Implementation
The company was looking for a technical platform that lets users
concentrate on the actual contents: The data structures and functionalities. The system already provides basic mechanisms such as
user administration, version management and client-server architectures. That is why the choice was made to go with the eASEE Tool
Suite from Vector.
3.1 eASEE as Technology Platform

eASEE is a process tool whose core consists of a hierarchical configuration management system for any desired data. This basic system
includes:
> Functions for versioning and var iant formation
> A user-configurable data model for user data and meta data
> A workflow engine
> Multi-site operation, and
> A dif ferentiated roles and rights concept.
Overlaid on this basic system are modules specif ically designed for
var ious process areas. These modules cover the major ity of key
process functionalities that are needed in the automotive industry
[Figure 2]. Programming inter faces are provided to allow for individual extensions. Besides being used at MAN, eASEE is also used at
Bosch, General Motors, Daimler, ZF, Volvo, Porsche, VW, Audi and
Getrag.
3.2 The MAN Common Engineer ing Data Backbone
Figure 1:
Single-source principle for the development process
8/2
Today, the MAN Common Engineer ing Data Backbone consists of

eight domains. Its foundation is an Oracle database upon which the
eASEE Tool Suite is placed [Figure 3].
The process model distinguishes between the actual development
process (Do it) [Figure 1] and the management process (Control
it) [Figure 4]. Analogously, in the MAN Common Engineer ing Data
09.02.2010
13:06 Uhr
Seite 2
Figure 2:
The eASEE process tool suite
Backbone there are Do it data domains (FDM, TDM, CDM, etc.),

and a Control it project management domain (PPM) [Figure 3].
The two areas are interlinked across all domains. Project schedules
(Gantt Charts), for example, are automatically updated based on
the states of the elements in the data domains. Thus, the project
leader no longer needs to per form maintenance work on the states
of work packets.
Function Data Management FDM

The individual data domains are oriented directly toward the process.
Function Data Management (FDM), for example, represents the left
side of the V-Model. This domain contains a complete meta model
used to describe all of the data of an electronic structure, including:
> Vehicle configurations
> ECUs
> Hardware (connectors/pins)
> Signals (e.g. CAN)

> Vehicle functions
> Functions
> Software architectures.
In addition, a classic requirements management system is represented.
Based on these data structures, the FDM of fers many functionalities
for the daily tasks of the engineer. These include:
> Var ious inter faces to expert tools, e.g. Matlab/Simulink/TargetLink as a development environment and XMetaL as an XML-based
author ing environment for detailed specifications [Figure 5]
> The option of a vir tual vehicle design/check,
> Signal path analysis
> Ability to generate DBC files to describe bus systems for analysis
and test tools such as Vectors CANalyzer and CANoe.
Figure 3:
MAN Common Engineer ing Data
Backbone
8/3
09.02.2010
Test Data Management TDM

The right side of the V-Model is covereded by Test Data Management
(TDM). In this domain it is possible to map entire test projects.
Among other things, TDM manages the test specifications, test execution information for each test, test results, test environments
and test methods. Test data in the TDM are directly linked to development data in the FDM. Since the system is used cross-departmental and over all test levels, it is possible and very easy to draw conclusions about test coverage from component testing to validation testing.
Seite 3
tools such as CANape, INCA or Caldesk which have an ASAM

MCD2MC inter face and which support the CDF or DCM exchange format may be read directly into the CDM. Completed and released
parameter sets may be referenced in the FDM as initial data sets.
Service Data Management SDM

Service Data Management (SDM) makes it possible to provide servicerelevant data to the service area from the development area. Also represented in this system is a workflow mechanism that tracks the path
from the released ECU to its production and use in series vehicles.
Fault and Requirement Management FRM
Traceability
Fault and Requirement Management (FRM) contains a complete

change management. This system can be used to input issues into
the development process. The individual issues may be classified as
errors or new requirements.
Errors are linked to both the test cycle in which the error was found,
in the TDM, as well as to the function in which the error occurred.
This makes it very easy for function developers to look in the FDM to
see which issues are still open for them. The test engineer, in turn,
sees very quickly which errors were corrected in a new function version, and what form of post-testing is necessary.
Today, almost all data generated in the development process is

saved in a meta model in the MAN Common Engineer ing Data Backbone. Integrated data storage in a database enables nearly per fect
traceability of the data. For example, starting from a test cycle it is
possible to determine which error was found with this test cycle
and which requirement the test cycle covered.
Another potential use is to start with a CAN signal and have the system indicate which functions in an electronic structure utilize this
signal. For example, it is possible to deduce whether a cer tain sensor can be omitted in the system.
Calibration Data Management CDM
3.3 Status of the MAN Common Engineer ing Data

Backbone
Calibration Data Management (CDM) maps the data of the calibration process. Based on the data of the FDM, in calibration projects
this system makes it possible to manage data records of ECUs via
the ASAM MCD-2MC file. Data records from established calibration
Figure 4:
Planning and control of the development process
8/4
13:06 Uhr
The MAN Common Engineer ing Data Backbone has been in productive operation for several years and is currently utilized by about
one hundred developers. Today it consists of the eight domains
Figure 5:
FDM inter face to Matlab/Simulink
09.02.2010
13:07 Uhr
Seite 4
TOOL-SUPPORTED DATA AND PROCESS MANAGEMENT AT MAN NUTZFAHRZEUGE AG
Figure 6:
FDM inter faces to author ing tools
and exter nal databases
described and var ious inter faces [Figure 6]. Since developers are
actively supported by the backbone in their daily work, from the
first requirement to the last test, the Common Engineer ing Data
Backbone is very well accepted by developers. It has been shown
that it is very impor tant for developers to work within the system
from the very first minute, and to single-source their data here.
This eliminates an additional maintenance ef fort that would other wise be perceived as rather disruptive.
4 Utility
After about three years of productive use by the Common Engineer ing Data Backbone, the initial objectives were realized. Ef ficiency
gains were achieved due to redundancy-free data input and data
storage and due to the many dif ferent options for supplying information and prepar ing data. Previously, an engineer would have to
work through dozens of documents to predict the consequences of
transferring a cer tain function from ECU A to ECU B. Today, it takes
just a few mouse clicks and the relevant information is available at
the latest revision level. Another advantage is reusability of engineer ing ar tifacts and data, which is made possible by Var iant Management. Other positive ef fects are the considerably improved
transparency for engineers involved in the development process
and the ability to establish role-specif ic views for one and the same
data content. Thus, the MAN Common Engineer ing Data Backbone
of fers very specif ic views of development status, e.g. for the project leader, system architect, function developer, integration manager and test engineer.
established standards such as MSRSW and ASAM were used. Today,

this is very beneficial especially at supplier inter faces. Therefore,
MAN is following the development of the AUTOSAR standard very
closely. If the advantages of the standard appear suf ficiently great,
the MAN Common Engineer ing Data Backbone would be adapted to
the AUTOSAR standard and brought to a level of AUTOSAR compatibility. The interests of MAN and Vector overlap here too: The Stuttgart-based tool producer has set the goal of developing an eASEE
module for AUTOSAR-compatible system data management, which
combines the advantages of the standard with key functionalities
of the Common Engineer ing Data Backbone.
Stefan Teuchert
(Graduate Engineer) manages the Software
Development and Basic Technologies department at MAN Nutzfahrzeuge AG
Georg Zimmermann
(Graduate Engineer) manages the Product
Line Process Tools department at Vector
Informatik GmbH
5 The Road Ahead

In implementing the MAN Common Engineer ing Data Backbone,
special attention was given to exchange formats to ensure that
8/5
09.02.2010
13:12 Uhr
Seite 1
From Pilot Studies to Production Development

Ef ficiency and Quality in
calibrating Transmissions
To soundly manage growth in the number of complex transmission calibration
projects and their data at ZF Friedrichshafen AG, the company needed to introduce a new calibration data management system. Deciding factors for introducing the calibration data management
system eASEE.cdm from Vector were the
tools high functionality, flexibility and
potential. Another crucial factor was the
companies development partnership
over many years with the goal of jointly
meeting ZF targets for quality assurance
and improved ef ficiency.
To be successful as a globally-active automotive supplier in a market character ized by innovation, competition and cost pressure, it
is necessary to have products that meet the stringent technical and
economical requirements of automotive OEMs.
Based on its comprehensive expertise, continuously optimized processes and process tools, ZF is able to position its products for powertrain and chassis systems very successfully in the market. In the
power train area, ZF supplies transmissions for passenger cars, commercial vehicles, buses, rail vehicles, ships and helicopters. These
areas are marked by a very high level of model diversity. This diversity
in models and var iants can be achieved by vehicle-specif ic parameter ization (calibration) of the transmission. For example, ZF supplies
the 6HP26 6-speed automatic transmission, which enables ef ficient
gear shifting in dif ferent vehicles with vehicle-specif ic torque curves
ranging from 300Nm to 800Nm; this is accomplished by individual
parameter ization (Figure 1). Short shift times, smooth gear shifts,
reduced fuel consumption and low emissions are other objectives
that can be met by optimally adapting parameters to the vehicle.
Objectives for the new calibration data management system were:

> Uniform and corporate-wide system for central management of
all ZF drive and chassis projects
> Introduction of a modern, market-established Engineer ing Data
Management system (EDM system) with a database orientation
> Support and standardization of defined calibration processes
> Integrated checking and test routines for quality assurance
> Mass operations to improve ef ficiency
> Flexibility of data storage from simple addressing via var iantencoded groups for multiple systems or vehicles to complex data
storage for many vehicles
Requirements of ZF Friedrichshafen AG
Even the first microcontroller-based transmission control electronics included parameters for adapting the electronics to the environment (e.g. transmission hardware, vehicle). Starting with just a few
calibration parameters, the number of parameters continually rose
in response to increasing functionality. A growing model diversity
in transmission and power train systems as well as a rising number
of parallel projects required functions for central, ef ficient and
process-conformant management of the calibration data. The existing system for data management developed in-house at ZF had
been stretched to its limits by the complexity of projects.
8/6
Figure 1:
The 6HP26 transmission from ZF
Vectors eASEE.cdm Solution

To fulfill the requirements outlined by ZF, a tool was needed that
integrates the functions of EDM systems, process tools and calibration tools in a comprehensive system solution. In deciding on
eASEE.cdm from Vector, ZF chose a mature and market-established
system.
The eASEE.cdm calibration data management system consists of a
data management system for engineer ing ar tifacts and a graphic
Parameter Editor; it also contains calibration-specif ic functions and
automated sequences for managing all program and data sets occurring in the calibration process. As a modular component of the
eASEE tool suite, it is also easy to integrate it with other process
domains (Figure 2).
Functions of the eASEE base system include:
> Functions for versioning, and for forming var iants and
configurations
> Flexibly configurable data model for productive data and the
meta-data that describes it
> A workflow engine for process-conformant flow control
> Multi-site operation for cooperation between distributed
work teams
> A dif ferentiated roles and rights concept
Flexible configurability of the data model makes it easy to implement application-specif ic extensions eASEE.cdm becomes the data backbone of calibration processes.
09.02.2010
13:12 Uhr
Seite 2
Calibration-specif ic functions support project leaders, data integrators and calibrators in all phases of a project. From project def inition to data preparation to release of the integrated overall
parameter sets, users benefit from calibration data management
system functionality:
Project leaders at ZF are able to clearly structure complex calibration projects that have many var iants by proper ty-supported var iants management. Data set var iants are formed by combinations of
var iant-relevant attributes. Var iant criteria are also utilized as
filter criteria in releasing parameters (Figure 3).
ECU suppliers of ten per form calibration projects jointly with the
OEM, and this requires flexible handling of data. Calibrators at ZF
process and manage ECU parameters either parameter-oriented,
function-oriented, component-oriented or var iant-coded, depending on the specif ic calibration process. The CANape and INCA calibration tools that are used generate market-relevant data formats:
both physical character istic data formats (CDF, CSV, DCM, PaCo,
PAR) and program formats (Intel Hex, Motorola-S) are supported.
The calibration area at ZF implements the graphic Parameter Editor
for checking, adjustment and data integration (Figure 4). It of fers
extensive options for visualization (table-format, 2D and 3D) and
off line editing of ECU programs and parameters. Changes are saved
directly in the eASEE data backbone.
Data integrators make extensive use of algorithms to improve data
consistency and integrity by checking for completeness, unambigu-
Figure 2:
The eASEE process
tool suite
8/7
09.02.2010
ity and physical limits. Project leaders at ZF appreciate the added

security of fered by label-based rights management, which prevents
parallel releases of overlapping data. Other impor tant functions
have been integrated in the calibration data management system,
such as checksum generation and the ability to inter face to signature tools for protecting ECU software.
Introduction of the System

The decision to implement eASEE.cdm as a corporate-wide solution
at ZF was made in 2003. Before roll-out in the individual business
areas, eASEE.cdm was first introduced and evaluated in two pilot
projects. After successfully completing the pilot phase, the system
was introduced to daily business operations in 2004. The first production projects were the ECOMAT (automatic transmission for city
buses) and ASTRONIC (automatic transmission for trucks and buses)
projects. Today, approx. 150 calibration engineers manage project
and calibration data for 20 projects in dif ferent domains. This enables customer-specif ic separation of project data.
Implementation of ZF requirements was based on a multi-year development partnership. Close cooperation made it possible to meet
targets in a timely way. The focus in implementing requirements
was on general usability of the jointly developed functions.
Figure 3:
Proper ty supported var iants management
8/8
13:12 Uhr
Seite 3
Utility
Production calibration projects at ZF are per formed using calibration processes that are defined area-wide. The processes are structured so that many process steps can be run in parallel and executed by an automated tool. All aspects of this calibration process at
ZF are fully supported by eASEE.cdm. It ensures process-conformant execution of calibration projects in practice, and it supports of
calibrators, developers and project leaders.
In their daily work, users benefit from the following functionalities:
> Improved cooperation of calibration teams due to uniform and
corporate-wide system
> Data freeze time is reduced from one week to one day by
automated checking and safeguarding functions
> Reduced manual ef fort by automated generation of the data
exchange containers
> Reproducibility of data revision levels by automatic storage of
test and signature configurations
> Ef fective var iants management reduces number of time-wasting
and error-prone actions
> Collision-free data integration by label-based rights
management
> Full traceability of the calibration process by thorough
versioning of all relevant data and protocols
> Reusability of calibration data by component library
09.02.2010
13:12 Uhr
Seite 4
FROM PI LOT STUD IES TO PRO DUC TION DE VEL OP MENT
Summary
The eASEE.cdm calibration data management system has been
introduced corporate-wide at ZF, facilitating ef ficient, process-conformant data management while ensur ing high data quality.
Besides being used to support the business operations, the tool
also serves as an impor tant foundation in conducting (SPICE)
assessments of ZF business processes in software development and
calibration.
All of the objectives ZF sought to achieve were fully attained.
Signif icant increases in ef ficiency of up to 90% were attained in
safeguarding and signing-off data sets. Overall, eASEE.cdm is making an impor tant contribution toward reducing costs in calibration.
Rainer Rhrle
studied Physical Technology and Computer
Engineer ing and has been employed at ZF
since 1997. He is responsible for tool development in the Electronics/Software area.
Since 2003 he has been project leader for the
corporate-wide introduction of eASEE.cdm.
Christoph Heller
studied Electrical Engineer ing at the University of Stuttgart. He works at Vector Informatik GmbH as Business Development Manager
in the Process Tools product line area.
Figure 4:
Parameter editor
8/9
Press Book_Rueckseite:Press Book_Ruckseite
09.02.2010
13:11 Uhr
Your Con tact

Germany and all countries
not named below
Vector Consulting Services GmbH
70499 Stuttgart
GERMANY
Tel.: +49 711 80670-0
Fax: +49 711 8067-111
USA, Canada, Mexico

Vector CANtech, Inc.
Suite 550
39500 Orchard Hill Place
Novi, Mi 48375
USA
Tel.: +1 248 449 9290
Fax: +1 248 449 9704
France, Belgium, Luxembourg
Japan
Vector France
168, Boulevard Camlinat
92240 Malakoff
FRANCE
Tel.: +33 1 4231 4000
Fax: +33 1 4231 4009
Vector Japan Co., Ltd.

Seafort Square Center Bld. 18F
2-3-12 Higashi-shinagawa,
Shinagawa-ku
Tokyo 140-0002
JAPAN
Tel.: +81 3 5769 7800
Fax: +81 3 5769 6975
Sweden, Denmark, Norway,

Finland, Iceland
Korea
VecScan AB
Theres Svenssons Gata 9
41755 Gteborg
SWEDEN
Tel.: +46 31 764 7600
Fax: +46 31 764 7619
Vector Korea IT Inc.

1406 Mar io Tower
222-12 Guro-dong, Guro-gu
Seoul 152-848
REP. OF SOUTH KOREA
Tel.: +82 2 8070 600
Fax: +82 2 8070 601
United Kingdom, Ireland
India
Vector GB Limited
Rhodium, Central Boulevard
Blythe Valley Park
Solihull, Birmingham
West Midlands, B90 8AS
UNITED KINGDOM
Tel.: +44 121 50681-50
Fax: +44 121 50681-69
Vector Informatik India Prv. Ltd.

4/1/1/1, 3rd floor, Sutar Icon
Sus Road
Pashan
Pune 411021
INDIA
Tel.: +91 20 2587 2023
Fax: +91 20 2587 2025
China
Shanghai Representative Office
Suite 605, Tower C,
Everbright Convention Center
No. 70 Caobao Road, Xuhui District
Shanghai 200235
P.R. CHINA
Tel.: +86 21 6432 53530
Fax: +86 21 6432 5308
www.vector.com
Seite 3

Vector Press Book

Uploaded by

Copyright:

Available Formats

Vector Press Book

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vector Press Book

Uploaded by

Copyright:

Available Formats

What are the main topics covered in the document?

What are the main topics covered in the document?

What bus systems are discussed for data exchange in vehicles?

What bus systems are discussed for data exchange in vehicles?

Press Book_Einleitungsseiten:Einleitungsseiten

Dr. Thomas Beck

Serial Bus Systems in the Automobile: Introduction

Serial Bus Systems CAN

Serial Bus Systems in the Automobile: CAN

Serial Bus Systems LIN

Serial Bus Systems in the Automobile: LIN

Network Development across LIN Bus Systems

Assuring the Quality of LIN ECUs

Serial Bus Systems in the Automobile: FlexRay

The Optimal Operating System for FlexRay-Based Applications

Embedded Software for FlexRay Systems

FlexRay becomes daily Routine

Case Study: Bertrandt

FlexRay Sets the Pace

Efficient Access to the FlexRay Bus

AUTOSAR PDUs Conquer FlexRay

Serial Bus Systems MOST

Serial Bus Systems in the Automobile: MOST

Efficient Testing in Automotive Electronics

Reliable Engineering Testing on a Wiper Motor Test Bench

Case Study: Nippon Seiki Co., Ltd.

Comprehensive ECU Tests with Fault Simulation

Semi-Synthetic Regression Tests with Real-World Data

Model-Based Testing for Better Quality

Efficient Airbag ECU Tests

Vehicle Diagnostics - The whole Story

Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration

A Source Code Generator Approach to Implementing Diagnostics in Vehicle ECUs

ECU Software for Dry Dual Clutch has Stringent Requirements

Flexible Flash Solution for every Job

Flash Programming via CAN requires Suppliers Flexibility

Serial Bus Systems FlexRay

Use of XCP on FlexRay at BMW

XCP at the Focal Point of Measurement and Calibration Applications

Quantum Leap in Microcontroller Measurement Technology

Efficient Analysis of Model Behavior in ECU Function Development

Accelerated Turbocharger Development with CANape

Optimizing Driver Assistance Systems

Trends in Embedded Development

Timing, Memory Protection and Error Detection in OSEK Systems

Current Challenges in Automotive Networking

The Universal Gateway ECU

Early Migration creates Opportunitites for Innovations

AUTOSAR on its Way to Production

AUTOSAR: New Paths to ECU Software Part 1

AUTOSAR: New Paths to ECU Software Part 2

Networking Heavy-Duty Vehicles Based on SAE J1939

CAN and J1939 under Extreme Duty Conditions

Current Trends in Network Development for Heavy-Duty Vehicles

Open Networks - ISOBUS

Automatic Interoperability Tests for ISO11783 Systems

Wireless Analysis in a Multi-Protocol CAN Environment

Prototyping and Testing CANopen Systems

Automatic Testing of CANopen Devices