You are on page 1of 252

Press Book_Einleitungsseiten:Einleitungsseiten 09.02.

2010 14:27 Uhr Seite 1

Press Book
1 st Edition
Press Book_Einleitungsseiten:Einleitungsseiten 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
Press Book_Einleitungsseiten:Einleitungsseiten 10.02.2010 12:05 Uhr Seite b

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 cali-
bration 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
Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite c

Contents

Serial Bus Systems Serial Bus Systems in the Automobile: Introduction 1/0
Motivation, advantages, tasks and architecture of serial bus systems in the automobile
Serial Bus Systems – CAN Serial Bus Systems in the Automobile: CAN 1/6
Reliable data exchange in the automobile with CAN
Serial Bus Systems – LIN Serial Bus Systems in the Automobile: LIN 1/12
Simple and cost-effective data exchange in the automobile with LIN
Network Development across LIN Bus Systems 1/18
Tools for efficient network design and conformance testing
Assuring the Quality of LIN ECUs 1/22
Current and future strategies for LIN Master conformance tests
Serial Bus Systems – FlexRay Serial Bus Systems in the Automobile: FlexRay 1/26
FlexRay for data exchange in highly critical safety applications
The Optimal Operating System for FlexRay-Based Applications 1/32
Embedded Software for FlexRay Systems 1/38
Special aspects and benefits of implementing modularized software
FlexRay becomes daily Routine 1/42
Analyzing, simulating, and testing FlexRay ECUs and networks using CANoe.FlexRay
Case Study: Bertrandt 1/45
FlexRay Sets the Pace 1/46
Real-time simulation of FlexRay systems
Efficient Access to the FlexRay Bus 1/50
High-performance FlexRay hardware for analysis and simulation
AUTOSAR PDUs Conquer FlexRay 1/54
Audi benefits from CANoe.FlexRay in developing FlexRay networks with PDU communication
Beyond FlexRay 1/58
Requirements on a modern development environment
Serial Bus Systems – MOST Serial Bus Systems in the Automobile: MOST 1/62
MOST for transmission of multimedia data

ECU Testing Efficient Testing in Automotive Electronics 2/0


One test environment from HIL simulation to diagnostics
Reliable Engineering Testing on a Wiper Motor Test Bench 2/8
Time-synchronous recording and evaluation of bus messages and physical parameters
Case Study: Nippon Seiki Co., Ltd. 2/13
Comprehensive ECU Tests with Fault Simulation 2/14
Fault simulation capability is needed in early test phases for efficient functional tests
Semi-Synthetic Regression Tests with Real-World Data 2/20
Reducing time and hardware effort in software evaluations
Model-Based Testing for Better Quality 2/24
Advantages of test case generators in model-based development processes
Efficient Airbag ECU Tests 2/28
Increase efficiency by automated tests during development

Vehicle Diagnostics Vehicle Diagnostics - The whole Story 3/0


Efficiency gains by standardization and the use of tool-supported processes
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration 3/8
and Validation Assistant
A Source Code Generator Approach to Implementing Diagnostics in Vehicle ECUs 3/16
ECU Software for Dry Dual Clutch has Stringent Requirements 3/20
Integrated diagnostic and flash solution with script control
Flexible Flash Solution for every Job 3/24
Open standards enable use of generic tool chains
Flash Programming via CAN requires Supplier’s Flexibility 3/28
Satisfying strict requirements of Vehicle OEMs
Press Book_Einleitungsseiten:Einleitungsseiten 09.02.2010 14:27 Uhr Seite d

ECU Calibration Use of XCP on FlexRay at BMW 4/0


XCP-on-FlexRay at Audi 4/4
AUTOSAR-compatible XCP software modules for FlexRay ECUs
XCP at the Focal Point of Measurement and Calibration Applications 4/10
Quantum Leap in Microcontroller Measurement Technology 4/16
Innovative ECU measurement concept for maximum data rates with
minimal effects on execution time
Efficient Analysis of Model Behavior in ECU Function Development 4/20
Visualize and parameterize Simulink models easily and efficiently
Accelerated Turbocharger Development with CANape 4/24
Efficiently developing control concepts with a cost-effective rapid prototyping solution
Optimizing Driver Assistance Systems 4/28
Verification of object recognition algorithms by driver assistance systems

ECU Software Trends in Embedded Development 5/0


Requirements and future concepts in hardware, software and tools
Timing, Memory Protection and Error Detection in OSEK Systems 5/4
Requirements on a real-time and multitasking operating system

AUTOSAR Current Challenges in Automotive Networking 6/0


Reusability of software modules at Volkswagen and Bosch
The Universal Gateway ECU 6/4
Flexible post-build configuration of AUTOSAR gateways
Early Migration creates Opportunitites for Innovations 6/10
Mix of individual software and AUTOSAR components in vehicle electronics
AUTOSAR on its Way to Production 6/14
AUTOSAR: New Paths to ECU Software – Part 1 6/18
Iterative collaboration between OEM, TIER1 and software supplier
AUTOSAR: New Paths to ECU Software – Part 2 6/24
AUTOSAR in practice – Life cycle of AUTOSAR ECU software

Open Networks - SAE J1939 Networking Heavy-Duty Vehicles Based on SAE J1939 7/0
From parameter group to plug-and-play application
CAN and J1939 under Extreme Duty Conditions 7/6
Vehicle electronics guarantees functionality in cold, ice and snow
Current Trends in Network Development for Heavy-Duty Vehicles 7/14
Factors of success in electronic development
Open Networks - ISOBUS Automatic Interoperability Tests for ISO11783 Systems 7/18
Universal test solution assures compatibility
Open Networks - IP Wireless Analysis in a Multi-Protocol CAN Environment 7/22
Moving Communication 7/26
Wireless analysis of in-vehicle networks
Open Networks - CANopen Prototyping and Testing CANopen Systems 7/30
Reaching goals rapidly with minimal effort
Automatic Testing of CANopen Devices 7/34

Process Management Before considering Tools it is easy to have a Handle on the Process first 8/0
Interview about the management of engineering and management processes
in the E/E development
Tool-supported Data and Process Management at MAN Nutzfahrzeuge AG 8/2
An integrated development database manages all engineering data in
the E/E development process
From Pilot Studies to Production Development 8/6
Efficiency and quality in calibrating transmissions
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 auto-
mobile is growing from year to year. Electronics
plays a decisive role, not only in satisfying prima-
ry 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 con-
tribution by numerous serial bus systems in the auto-
mobile. Many functions would not even be possible
without data exchange between electronic compo-
nents. 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 communication channel integrates all individual communi-
in the automobile cation channels and is referred to as a bus. Using this bus
Recent history of the automobile is character ized by inten- and associated serial inter faces it is possible to join all ECUs
sive electronification. The driving force for this originates together into a network refer to as a serial bus system (Fig-
primarily from customer expectations of a modern automo- ure 1). In this context, ECUs are referred to as bus nodes.
bile which are becoming increasingly demanding. Moreover,
legislators are continually placing stricter requirements on Since the introduction of serial bus systems, the complex
exhaust emissions. The rising competitive and cost pressures and of ten divergent types of wire harnesses in the automo-
of globalization also produce constant innovative pressure. bile have become a thing of the past. Bus systems not only
Automotive OEMs have found electronics to be a way to meet simplify project design and installation, but also reduce the
this multiple challenge. Par ticularly this is reflected in the weight and space required for wir ing. Moreover, the lower
migration of electronic control units (ECUs) into the auto-
mobile which began at the end of the 1970s.

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 func-
tionality immensely. This was the motivation for integrating
communication systems in the automobile.

Ahead of everything else, at that time it was electronic driv-


Figure 1:
ing dynamics control that dominated advanced develop-
Bus networking: All electronic control units (Black:
ment. However the intensive wir ing ef fort utilizing individu- Bus nodes) are joined into a system network, the serial
al dedicated lines only permitted limited data exchange. As a bus system, by means of a bus and related serial inter -
way out of this dilemma, bit-serial data exchange via a sin- faces.
gle communication channel came into question. This single

1/0
01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/1

number of connectors reduces the susceptibility to failure The most pressing tasks of a serial bus system include real-
signif icantly. These many advantages face numerous com- time communication and data integrity. A distributed system
munication tasks that must be mastered by the serial bus can only fulfill its intended purpose if all data reach the des-
system. The most impor tant communication tasks are dis- tination node in time and without errors. A serial bus sys-
cussed in the following. tem’s per formance and field of application in the automobile
substantially depend on the degree with which it can avoid,
Communication tasks reject, detect and correct errors, and can guarantee timely
A precondition for trouble free serial data exchange is the data transport.
unique allocation of the data to be sent to the bus nodes. Es-
sentially a distinction is made between sender-selective and Data integrity
receiver-selective allocation (addressing). In case of sender- Quantitatively data integrity can be described as the residual
selective addressing the sender identifies the desired receiv- error probability. This is a statistical measure of data integri-
er by a unique bus node address. In contrast, in case of re- ty violation. Residual error probability is understood as the
ceiver-selective addressing the data to be sent are ad- product of probability A that the transmitted data are cor-
dressed. This means in principle that all data are available rupted and probability B that the corrupted data remain un-
for any node to receive (Broadcast). Therefore all bus nodes detected. The data integrity of a serial bus system therefore
have the task of filter ing out data that are relevant to them. depends first on the extent to which it avoids the corruption
This is accomplished with the help of the address referred to of data, and second on the degree to which it can detect cor-
here as identifier. rupted data.

In order that the receiver acquire the data and address as Var ious interactions related to electrical, capacitive or in-
one unit, the sender packs both of them together as a frame. ductive coupling, as well as electromagnetic fields, come in-
A typical frame encompasses the address and data with a to consideration as potential causes of data corruption in
start and end recognition, which are primarily used to syn- the automobile. Specif ic sources responsible for corruption
chronize senders and receivers. A “frame” is also referred to might be actuators, fan motors, high-frequency signals gen-
as a “message”. erated by the commutation process in DC motors and fast da-

Figure 2:
Controlled and
random bus access.

1/1
01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/2

ta transmissions or reflections at the ends of buses. The The more clever the algorithm, the shorter the data block to
more successfully these causes can be eliminated, the great- be protected and the longer the checksum, the better the al-
er the noise immunity and more reliable the data transmission. gorithm’s error detection ability. However, due to limited
bandwidth and time requirements, a compromise must be
To enhance the noise immunity of a serial bus system, cer - reached between error detection ability and the ratio be-
tain impor tant measures are necessary. Besides shielding tween data block and checksum size (transmission ef ficien-
the transmission medium, as well as all electrical and elec- cy). Fur thermore one must consider that the checksum itself
tronic components, it is impor tant to provide suf ficiently is not immune to disturbances dur ing transmission.
large distances between data and power transmission lines
and between electrical and electronic components. Fur ther- As a rule, after detecting a transmission error, error correc-
more, it is impor tant to limit the data transmission frequen- tion is needful, e.g. by means of an error-correcting check-
cy and number of data signal edges and their steepness, to sum. However, unlike simple error detection that would
apply the principle of dif ferential signal transmission and fi- require an explicit longer checksum. For ef ficiency reasons
nally to terminate bus ends with the character istic impe- error-correcting checksums are not implemented in the au-
dance of the transmission medium. Even with optimal physi- tomobile. The error correction happens by repeating the
cal system design transmission errors cannot be eliminated message: caused either by an error flag set by the bus node
entirely. Error detection mechanisms are therefore essential. detecting the error, or automatically in the case of periodic
Among the most frequently utilized methods is the checksum message transmission.
method, wherein the sender computes a checksum from the
data block to be sent by a defined algorithm. It then sends Real-time capability
this checksum at the end of the data block. Using this check- A system with real-time capability must be able to guarantee
sum the receiver is able to ver ify the received data block. transmission of all data to be exchanged between the var i-
ous bus nodes within a defined time window. Key factors

Figure 3:
Simplified architec-
ture of serial bus
systems.

1/2
01 Press Book_Seite_1-00_1-05:Press Report 1 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 other hand, covers all aspects of the Physical Layer, from the
bandwidth, and especially the type of bus access. In the lat- physical bus inter face to physical signal transmission over
ter case a fundamental distinction is made between con- the bus.
trolled and random bus access (Figure 2).
Generally the physical bus inter face is implemented with the
In serial bus systems with controlled bus access, bus access help of a transceiver. A communication controller covers the
rights are already clearly defined before the bus access. Such Data Link Layer. If all of the bus nodes within the system fol-
systems of fer deterministic message traf fic as an impor tant low the same communication protocol and the same Physical
precondition for attaining real-time capable serial bus sys- Layer specification, then the fundamental preconditions for
tems. However, since the entire communication sequence is trouble-free data exchange between the bus nodes are satisfied.
executed according to a schedule and cannot be influenced,
serial bus systems with controlled bus access are character - In serial communication the sender’s application passes to
ized by poor dynamic behavior. the communication controller the data block to be sent. The
communication controller in turn adds the address and
This disadvantage does not apply to bus systems with uncon- checking and synchronization information to the data block,
trolled bus access. Each bus node has the right to occupy the thereby creating a frame. The transceiver now transmits the
bus at any time, e.g. in response to an event that just oc- frame over the bus. In the automobile the physical intercon-
curred. This produces very fast bus access; however there is nection structure is generally the line topology, which is very
the inherent risk of more or less acute collisions, depending easy to manage due to the passive bus inter face. On the re-
on the event density, message sizes and the available data ceiver side the transceiver accepts the frame and passes it to
rate. These are not good conditions for achieving real-time the communication controller, which evaluates the informa-
capable data transmission. tion transmitted to it and in case of correct data reception
routes the data block to the application.
Monitor ing of the bus by bus nodes wishing to send signif i- This results in a hierarchical and therefore transparent com-
cantly reduces the risk of collision. It can be prevented en- munication flow. This is guaranteed by completion of the
tirely by introduction of message prior ities. However, these communication tasks assigned to the layers, and by the com-
bus access methods based on bus monitor ing and message munication protocol and def inition of the Physical Layer
prior ities cannot guarantee timeliness. It is possible, that (Figure 3).
low-prior ity messages will be delayed unreasonably long.
For some tasks such as bus management (including Sleep
Architecture of serial bus systems and bus nodes and Wake-Up functionality) or diagnostics and configuration
in the automobile of bus nodes, the communication functionality provided by
Based on the reference model for data communication speci- the Data Link Layer is insuf ficient. By def inition higher lay-
fied by ISO (International Standardization Organization), ers respectively higher communication protocols the com-
the serial inter face of a bus node in the automobile is typi- munication functionality can be expanded.
cally subdivided into two (communication) layers: A lower
layer (Physical Layer) and a layer above it (Data Link Layer). CAN, LIN, MOST and FlexRay
Intensified competition is contributing toward more and
Some of the tasks handled by the Data Link Layer are ad- more safety and convenience functions in the automobile.
dressing, framing, bus access, synchronization and error de- This not only results in a permanent increase in the number
tection and correction. These tasks are defined by a commu- of electronic components in vehicles, but also a substantially
nication protocol. The Physical Layer specification, on the greater degree of networking with rapidly escalating data

1/3
01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/4

volumes, since most new automobile functions cannot do CAN was developed in the early 1980s by Robert Bosch
without data exchange any longer. To keep the growing com- GmbH, and in 1994 it became an international standard
plexity of automotive electronics manageable, automotive (ISO 11898). Three of Vector’s executive directors played
OEMs create dif ferent standards on the system, functional key roles in its development, and in 1988 they founded
and communications levels. On the system or functional lev- Vector Informatik GmbH. LIN, MOST and FlexRay emanated
el, “AUTOSAR” (Automotive Open System Architecture) is ex- from non-proprietary organizations: The LIN Consor tium
pected to provide the necessary transparency in the future. (www.lin-subbus.org), MOST Cooperation (www.mostcooper-
Non-proprietary communication standards such as CAN, LIN, ation.com) and FlexRay Group (www.flexray.com). Although
MOST and FlexRay provide greater transparency on the com- they have not been of ficially standardized, they can be con-
munications level. sidered de-facto standards.

CAN (Controller Area Network) is used primarily in the pow- Reliable partner for ECU networking and data
er train, chassis and convenience areas. LIN (Local Intercon- exchange
nected Network) serves to achieve simple and cost-ef fective The specialists at Vector support automotive OEMs and sup-
data transmission in the sensor/actuator area. MOST (Media pliers in CAN, LIN, FlexRay and MOST networking with a uni-
Oriented System Transport) is implemented in infotainment versal tool chain of design and development tools as well as
to transmit video and audio signals. Finally, FlexRay enables software components and base software for AUTOSAR ECUs.
the most challenging communication in safety-critical dis- Advising, consulting services and tools for process manage-
tributed applications. Figure 4 shows an example of ECU net- ment supplement the application areas. Its services are com-
working with serial bus systems in a modern automobile. In plemented by a broad-based training program on Vector
contrast to CAN, LIN and MOST, however, FlexRay must first tools, software components and serial bus systems.
become established in the automobile. This fall the first
FlexRay production application will hit the streets. The Mu- For entry-level work in automotive ECU networking or data
nich automotive producer BMW is introducing the innovative exchange the Stuttgart-based company of fers the one-day
bus system in an active suspension control system on its new seminar “Serial bus systems in the automobile”. Fundamen-
X5 automobile. tals 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

Author: Outlook
Eugen Mayer (Graduate Engineer with Tech- Parts 2-5 of this series address the serial bus systems CAN,
nical Teaching Cer tif icate), after completing LIN, FlexRay and MOST in detail.
his vocational training to become a commu-
nications technician, studied electronics at
the Technical College in Ravensburg/Wein-
gar 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
01 Press Book_Seite_1-00_1-05:Press Report 1 09.02.2010 13:07 Uhr Seite 1/5

Developing automotive
OFUXPSLJOHJTOPUSFBMMZEJGæDVMU
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 cer-
tainly 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 trai-
ners. 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 col-
leagues from your field.
new?
thing
t r y some harge
to fc
Don‘t settle for less. And it costs less than you might think. Want our free o
tal:
Get a quick overview at our web pages. Visit
r n in g Por om
E-Le a
a r n ing.c
-ele
w .v ector
ww
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
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1

Serial Bus Systems in the Automobile

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

Figure 1:
CAN in the reference
model for data com-
munication (ISO
7498), CAN standard
and implementation.

1/6
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/7

communication lines (CAN-High and CAN-Low line), which hardware or software of existing bus nodes. However this is
are terminated with the character istic line impedance to only true if the added bus node is exclusively a receiver.
avoid reflections at the ends.
Event control
Message distribution The messages that are transmitted in a CAN network and
Message addresses and message filters are used in a CAN their sequence do not depend on a time progression, rather
network to organize nodes and messages. Message address- they depend on the occurrence of special events. Each CAN
es, commonly referred to as Identifiers (ID) do not identify node is in principle author ized to access the CAN bus imme-
the CAN target nodes, rather they identify the messages diately after an event occurs. Given its relatively short mes-
themselves, so that in principle all CAN messages are availa- sage length of max. 130 bits in standard format and its high
ble to be received by all CAN nodes (message distribution). data transfer rate of up to 1 MBit/s, this method enables
By means of a filter each CAN node selects those CAN messa- quick reactions to asynchronous events. This is an impor tant
ges from the message stream that are relevant to it (receiv- precondition for real-time capable data transmission in the
er-selective system). The 11 bit wide ID permits specification millisecond range (1 to 10 ms), which is primarily a require-
of up to 2048 CAN messages in a CAN network. ment of power train and chassis applications.

Message distribution of fers the following advantages: Since CAN communication is not based on any time schedule
> Cost savings by shared use of sensors, the message traf fic is not determined until runtime, and this
> Easy implementation and synchronization of distributed implies that it carries the inherent risk of collisions. This risk
processes, and above all: increases with increasing bus load, and it calls the real-time
> High flexibility with regard to the configuration. capability of the system into question. To assure real-time
This is because omitting node addresses makes it possible to data transmission in spite of random bus access, the
integrate other bus nodes without having to modify the CSMA/CA bus access method is utilized in the CAN network.

Figure 2:
CAN inter face and
CAN network.

1/7
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/8

CSMA/CA bus access method tration phase the CAN node that gets send author ization is
Bus access begins when a CAN node wishing to send first lis- the node transmitting the CAN message with the least signif -
tens to the CAN bus (Carrier Sense – CS). If the CAN bus is icant identifier. Lower prior ity CAN nodes first switch to the
available the CAN node may begin to transmit its message Rx state and access the CAN bus for a renewed send attempt
immediately. On the other hand, if it detects bus activity it as soon as the bus is free again.
must postpone its send request until the CAN bus is available
and the currently running message transmission has been Not only do the bus and arbitration logic prevent collisions
completed; in addition it must wait a duration of three bit (Collision Avoidance – CA), they also provide prior ity-con-
times (ITM Intermission). An ongoing message transmission trolled bus access: The lower the signif icance of the identifi-
is not interrupted in this method – bus access is nondestructive. er, the higher the prior ity of the CAN message, and this re-
sults in faster bus access. The CAN message with the smallest
If there are multiple CAN nodes wishing to send, bitwise ar- identifier (ID=0) will therefore be transmitted without delay.
bitration (Figure 3) prevents collisions from occurring in
spite of simultaneous bus access (Multiple Access – MA). In If the bus load is not too high, this type of random, nonde-
the framework of bitwise arbitration all CAN nodes wishing structive, prior ity-driven bus access facilitates correct and
to send place the IDs of the CAN messages they wish to send very fast bus access. On the one hand, it should be noted
bitwise on the bus, from the highest to the lowest signif icant that delays grow with increasing bus load, above all delays of
bit. The wired-AND bus logic (0=dominant) that forms the low prior ity CAN messages. In the worst case a situation may
basis of the CAN network ensures that there is always an un- arise in which CAN messages arrive too late at receivers or
ambiguous bus level. After adding on an ID bit, each CAN are suppressed entirely. On the other hand, the CSMA/CA bus
node compares the bus level with the level it sent. The arbi- access method produces a reciprocal relationship between
tration logic decides whether a CAN node may continue to network extension and maximum data rate. Dur ing bitwise
send or whether it must stop sending. At the end of the arbi- 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
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/9

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

reliably detect a dominant level. The bit time inter val should Following the SOF is the ID, which may be either 11 bits
therefore be sized such that signal propagation times on the (Standard-ID) or 29 bits (Extended-ID) in length. The stand-
CAN bus are fully compensated. A length extension to a net- ard format dominates in the automotive field. The extended
work therefore necessitates a longer bit time inter val, which format typically plays a role in conjunction with higher level
in turn defines a maximum usable data rate. protocols such as SAE J1939. The ID format being used is in-
dicated by the IDE (Identifier Extension) bit. Another bit
Data transmission switch (RTR bit – Remote Transmission Request) indicates
It is primarily Data frames that are responsible for data whether the frame is a Data or Remote frame.
transmission in the automobile (Figure 4). While in fact Re-
mote frames also exist for requesting data, they are hardly The 64 bit wide data field is available for transmitting useful
ever used since data transmission in the automobile is not information, in which the exact number of useful bytes is in-
typically request-based, rather it is primarily provided on dicated by a DLC (Data Length Code). Following the data
the information generator’s own initiative. The two types of field is the so-called CRC sequence (CRC – Cyclic Redundancy
frames have identical layouts; the only dif ference is that the Check). The sender generates the CRC sequence based on all
data field is omitted in the Remote frame. bits to be transmitted, a generator polynomial and a well-
defined algorithm. Independent of the message filter ing the
A basic prerequisite for transmitting Data and Remote fra- same process occurs at the receiving end with the arriving
mes is synchronism between sender and receiver. Since a bits. The two sequences are compared, and the acknowledg-
clock line has been omitted for reasons of cost and ef fort, ment is made after the recessive CRC delimiter in the Ac-
synchronism is achieved by signal edges and a well-defined knowledge slot (ACK slot). At the end of a Data frame, after
resynchronization mechanism. Each message transmission the recessive ACK delimiter, comes the seven bit long and re-
begins with transmission of the dominant synchronization cessive EOF (End of Frame).
bit (SOF – Start of Frame) and this generates the first signal
edge (Bus-Idle exhibits a recessive bus level). The receiver Data protection
ensures synchronization over the entire transmission by The probability that corrupted CAN messages will remain
evaluating each arriving signal edge and adapting its own undetected is extraordinarily low. It is estimated to be 4.7 x
bit timing as necessary. The bit stuff ing method ensures that 10-11 [2]. Responsible for this are error detection mecha-
a complementary bit (stuff bit) appears at the latest after nisms defined in the CAN protocol. On the receiver side, be-
five homogeneous bits, thereby providing a signal edge. sides the message-filter ing-independent CRC that is capable

Figure 4: Structure of the Data frame.

1/9
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/10

of detecting up to five errors within a CAN message, checks Error correction consists of repetition of the aborted CAN
are also made of the format (Form Check) and bit stuff ing message by the same sender as soon as the CAN bus is free
rule (Stuff Check). The sender per forms bit monitor ing and again (after the error delimiter and ITM). In designing the
evaluates the ACK slot. system it must be considered that the CSMA/CA bus access
method does not guarantee immediate repetition. The error
If one assumes an error rate of 10-3 in a CAN network, then recovery time depends on the prior ity of the message and
given an annual operating time of 1000 hours, a data rate of the bus load.
500 KBit/s, a mean bus load of 25 percent and a mean mes-
sage length of 80 bits, statistically speaking a corrupted CAN Node monitor ing
message will remain undetected by the CAN protocol just Error signaling by error flag gives each CAN node the capa-
once every 4000 years. What is understood as the error rate bility of terminating ongoing message transmissions. Since
is the ratio of corrupted CAN messages to the number of all this also applies to defective CAN nodes, such nodes are ca-
transmitted CAN messages. pable of bringing the entire CAN communication to a stand-
still. To prevent this each CAN node has network node moni-
As soon as an error detection mechanism signals a transmis- tor ing (Figure 5) that can disconnect (Bus off) a node found
sion error, the CAN node detecting the error terminates mes- to be defective based on error counters and rules for control-
sage transmission by placing an error flag (six dominant ling the error counters.
bits) on the CAN bus. The error flag intentionally violates the
bit stuff ing rule so that network-wide each CAN node per- Acknowledgment of received CAN messages
ceives what until then was a local error and responds by ter- In a CAN network each message transmission is acknowl-
minating the message transmission, i.e. by appending an er- edged simultaneously by all receivers in the ACK slot (in-fra-
ror flag. This method assures network-wide data consistency me acknowledgement), independent of message filter ing. A
which is so impor tant in distributed applications. 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 er-
ror 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 trans-
mission by sending an error flag.

Outlook
Until just a few years ago CAN was the most sought after bus
technology in the automotive industry. The relentless elec-
Figure 5:
tronification of the vehicle has caused CAN to encounter lim-
Network node monitor ing using two er ror counters and its. Vehicle developers are questioning the suitability of the
three node states. CAN bus especially in bandwidth-intensive, real-time, critical
and highly safety-critical motor vehicle applications such as

1/10
02 Press Book_Seite_1-06_1-11:Press Report 1 09.02.2010 13:10 Uhr Seite 1/11

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

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

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 pro-
jects we of fer universal tool chains of design and develop-
ment 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 require-
ments. These services are rounded out by a comprehensive
training program cover ing Vector tools, software compo-
nents and serial bus systems.
For an introduction to ECU networking or data exchange in
the automobile the Stuttgart-based company of fers the one-
day seminar “Serial bus systems in the automobile”. Funda- Author:

mentals seminars on CAN, LIN, FlexRay and MOST convey the Eugen Mayer (Graduate Engineer with Tech-
basic knowledge needed to quickly gain familiar ity with the nical Teaching Cer tif icate), after completing
his vocational training to become a commu-
many dif ferent development activities related to automotive
nications technician, studied electronics at
electronics [4]. the Technical College in Ravensburg/Wein-
gar ten, Germany, and studied electrical
engineer ing and vocational teaching at the
The first part of this series of ar ticles [5] addressed serial University of Stuttgart. Since 1999 he has
bus systems in the automobile in general terms. Upcoming been working at Vector Informatik where he
is employed as a Senior Trainer.
ar ticles three through five will discuss the LIN, FlexRay and
Tel. +49-711/80670-574, Fax +49-711/80670-111,
MOST serial bus systems. Interested readers will find supple- E-Mail: eugen.mayer@vector-informatik.de
mental and in-depth information on these topics that has al-

1/11
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 1

Serial Bus Systems in the Automobile

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? standard for the sensor/actuator area. With def inition of a simple
Growing demands of car users for driving conveniences have led to and cost-ef fective Physical Layer based on ISO standard 9141, as
wide-ranging electronification in this area of vehicle technology. well as a simple and lean communication protocol, the LIN Consor -
This is reflected in the migration of numerous electronic compo- tium has laid the foundation for success. It set the stage for imple-
nents into the convenience area. For a long time it was usual prac- mentation of simple and cost-ef fective bus nodes.
tice to interconnect the continuously increasing number of sensors,
actuators, stepper motors and DC motors directly to a central con- The LIN Consor tium not only focused on LIN communication itself,
trol module. but also provided a development methodology (LIN Work Flow), and
This trend gradually met with criticism: It led to a rapid increase in this fur thered acceptance of the bus system in the automotive in-
wir ing costs, along with greater space requirements, increasing dustry signif icantly. LIN Work Flow makes it is possible to automate
weight and signif icantly greater susceptibility to faults. In addi- the development of a LIN network (LIN Cluster), with resulting time
tion, growing individualization required many dif ferent wire har- and cost savings. The cornerstones of the development methodolo-
ness and connector var iants, which in turn made production, in- gy are two data exchange formats used to describe the entire LIN
stallation and maintenance considerably more dif ficult. 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 applica-
tion 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 sys-
tem for the sensor/actuator area. This technology has prevailed on
a broad front, and LIN can now be found in nearly all vehicles, typi-
cally in convenience applications such as climate control, seat ad-
justment, door controls and mirror adjustment.

LIN Consor tium assists in breakthrough


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

1/12
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 2

Serving to describe an entire LIN Cluster are the uniform syntax wire line is used. To assure suf ficient noise immunity in spite of this
(LIN Configuration Language) and the standardized LIN Descrip- method, the supply voltage and ground of the ECU electronics are
tion File (LDF). Defined in the LDF are all of a LIN Cluster’s proper - used as reference voltages for the bus level. A LIN transceiver ser-
ties, in par ticular communication relationships. Generator tools ves as the physical bus inter face. A level at least 40 % below the
utilize the LDF to generate the software components needed for LIN supply voltage is interpreted by the receiver as a logical “0”. Re-
communication. Additionally, the LDF provides necessary informa- ceivers interpret a level at least 60 % above the supply voltage as a
tion to analysis, measurement and testing tools and rest-of-bus logical “1”.
emulators.
The maximum data rate is limited to 20 KBit/sec to keep noise emis-
Similarly, the description of individual LIN nodes (LIN Slaves) is sions within limits. For line lengths up to 40 meters the maximum
given structure by the uniform syntax of the Node Capability Lan- recommended node count is 16. This takes into account the node
guage and standardized Node Capability Files (NCF). The NCF de- and line capacitances as well as the maximum allowable time con-
scribes the per formance character istics of a LIN Slave (including stant of the LIN Cluster prescribed in the LIN specification.
frame and signal def initions, bit rates, diagnostics) and in the fra- In terms of circuit technology a LIN Cluster is equivalent to an Open
mework of system design it represents the foundation for automat- Collector circuit. A pull-up resistor ensures that the bus level re-
ed generation of the LDF. mains nearly at the level of the supply voltage (High level) while
The two date exchange formats and the configuration process de- the Tx transistors of all LIN nodes are inhibited. The bus level is pul-
fined in the LIN specification let users implement a LIN Slave type led to nearly ground level (Low level) as soon as one of the Tx tran-
(e.g. stepper motor) multiple times in a LIN Cluster or use a LIN Sla- sistors is enabled. Accordingly, the Low state is referred to as the
ve in dif ferent LIN Clusters (reusability of LIN Slaves). dominant level and the High state as the recessive level.
Making just as impor tant a contribution to the success of LIN is de-
tailed documentation of the specification. LIN specification 2.1 Master-Slave communication
[2], in existence since November 2006, defines the Physical Layer, Communication in a LIN Cluster is based on a Master-Slave architec-
communication protocol, LIN Work Flow, LIN API as well as diagnos- ture. A cluster consists of a Master node (LIN Master) and at least
tics and configuration of the LIN nodes. one Slave node (LIN Slaves). For cost reasons, explicit communica-
tion controllers are not used. Instead LIN communication is imple-
Single-wire communication at rates up to 20 KBit/sec mented by software tasks in every node, the so-called Slave tasks.
The goal of creating a low-cost communication protocol for serial The LIN Master also has a Master task that is used to coordinate
data exchange in the non-safety-critical sensor/actuator area pri- cluster communication (Figure 2).
marily af fected the design of the Physical Layer. Physical signal
transmission in a LIN Cluster does not involve use of the dif ferential Coordination is achieved by means of periodic execution of the LIN
signal transmission familiar from CAN, rather a conventional single- Schedule that is organized in frame slots (Figure 3). At the begin-

Figure 2:
Master-Slave commu-
nication architecture:
All LIN nodes have a
Slave Task to par tici-
pate in communica-
tion in a LIN Cluster.
One LIN node also
has a Master Task for
controlling the LIN
communication.

1/13
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 3

ning of each frame slot the Master Task transmits a frame header An ID serves to delegate communication; it is six bits in length and
with a Frame Identifier (ID), which all LIN Slaves evaluate in their is protected by two par ity bits with even par ity and odd par ity. The
Slave Task. Immediately after the frame header a LIN Slave trans- ID and two par ity bits together are referred to as the PID (Protected
mits the frame response associated with the ID. The LIN Frame, Identifier). The first 60 IDs are available for useful data communi-
consisting of the frame header and frame response, is available to cation. The last four identifiers, ID 60 through 63, are reserved (of
be received by every LIN node (Broadcasting) due to ID-based mes- which ID 60 and ID 61 are used for diagnostic purposes).
sage addressing.
The frame response is composed of up to eight data bytes and a
Data transmission by LIN frames checksum for error detection. A distinction is made between the
Due to the lack of a communication controller, serial data transmis- classic and extended checksum. The classic checksum is the invert-
sion in a LIN Cluster is handled over the microcontroller’s serial in- ed modulo-256 sum of all data bytes. There is a transmission error if
ter face (Serial Communication Inter face - SCI) and is per formed result of adding the modulo-256 sum to the arriving data bytes
byte-by-byte. The SCI transmits each byte with the LSB (Least Sig- does not equal “0xFF”. The extended checksum also considers the
nif icant Bit) first, and the byte is framed by a start bit and a stop PID in forming the inverted modulo-256 sum.
bit (SCI frame). That is, a LIN frame is composed of a combination
of a number of SCI frames distributed between the frame header Since the LIN Slaves are usually equipped with very simple and low-
and frame response (Figure 4). cost microcontrollers, not only are they allowed to delay transmis-
sion of the frame response a little (Response Space), but they may
In transmitting the frame header the LIN Master per forms two key also insert sending pause (Interbyte Spaces) between transmis-
communication tasks: It synchronizes the LIN Slaves and delegates sions of SCI frames. Overall, this may lengthen the frame response
communication by assigning a sender and one or more receivers to by 40 percent. The same applies to the frame header, primarily be-
the frame response. cause there are dif ferent methods for generating the Sync Break. It
Due to cost sensitivity issues, the LIN Slaves may use on-chip reso- is absolutely essential to consider the 40 percent time reserve in
nators with a frequency tolerance of up to 14 percent. Therefore the designing the LIN Schedule.
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 Sporadic, Event Triggered and Diagnostic Frames
made up of at least 13 consecutive dominant bits, and it elicits a SCI The LIN specification contains provisions for making the communi-
error from all LIN Slaves. It is terminated by the Sync Break Delimit- cation cycle that is rigidly defined by the LIN Schedule more flexi-
er (at least one recessive bit). The LIN Master transmits the commu- ble and economical. The two frame types “Sporadic Frame” and
nication clock pulse with the subsequent Sync Byte (SCI Frame with “Event Triggered Frame” are provided for this purpose. In introduc-
the value 0x55). ing 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
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 4

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

A Sporadic Frame is understood as an Unconditional Frame that Request Frame” and “Slave Response Frame”. The Master Request
shares the same frame slot with other Unconditional Frames. Spo- Frame (ID=0x60) represents the Diagnostic Request. In this case
radic Frames are transmitted entirely by the LIN Master as necessa- the LIN Master transmits both the frame header and the frame re-
ry, so collisions are impossible. If the LIN Master has no need for sponse. For example, a Master Request Frame is transmitted if there
any of the frames, the associated frame slot simply remains empty. is a Diagnostic Request via CAN. The Slave Response Frame
(ID=0x61) corresponds to the Diagnostic Response. In this case the
The Event Triggered Frame was introduced to communicate sporadic LIN Master transmits the header, and the specif ic LIN Slave trans-
changes or events on the part of the LIN Slaves. It essentially corre- mits the response.
sponds to an Unconditional Frame, but with the dif ference that
multiple frame responses from dif ferent LIN Slaves are allocated to Management functions
the frame header. The frame response that is used to complete the The LIN specification defines Status Management and Network
Event Triggered frame header depends on the needs of the related Management. Status Management specifies that LIN Slaves must in-
LIN Slaves. There is a need when there are new data to be trans- form the LIN Master of transmission errors that are detected such
ported. The frame response of the Event Triggered Frame is identi- as par ity or checksum errors. This is done by a “Response Error Sig-
fied by the PID of the associated Unconditional Frame in the first nal” in an Unconditional Frame (“Status Frame”); however this fra-
byte. me does not contain any fur ther information on the type of error.
The LIN specification does not define error handling rather it leaves
In contrast to the Sporadic Frame, however, collisions cannot be this task to the user.
excluded in the Event Triggered Frame. In case of a collision the LIN
Master is responsible for transmission of all Unconditional Frames The primary task of LIN Network Management is to regulate the
assigned to the Event Triggered Frame. It does this by activating transition of all Slaves in a LIN Cluster from the normal communica-
and processing a “Collision Resolving Schedule”. tion state (Operational) to the Sleep state and in the other direc-
tion (Figure 5). If the LIN Slaves do not detect any bus activity for
Both conventional Unconditional Frames and special Diagnostic four seconds, they switch from the Operational state to the Sleep
Frames are suitable for diagnosing the LIN Slaves. Unconditional state. The same condition elicits a Sleep command from the LIN
Frames are used for simple signal-based diagnostics, while Diag- Master, which is really a special Master Request Frame.
nostic Frames are used either for user-defined diagnostics or diag-
nostics based on a standardized transport protocol [3] and uniform Conversely, when a LIN Slave detects a “Wake Up Signal” followed
diagnostic services [4] [5]. by a valid header it switches from the Sleep state via the Initializa-
The LIN specification defines two Diagnostic Frames: The “Master tion 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
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 5

dominant pulse minimum 250 microseconds and maximum 5 milli- LIN, FlexRay and MOST fundamentals convey the necessary basic
seconds in length, and it may be sent by any LIN node. The LIN knowledge needed to quickly become familiar with the wide variety
specification prescribes a maximum Initialization phase of 100 mil- of development activities related to automotive electronics.
liseconds, i.e. the LIN Master must begin to execute the LIN Sched-
ule at the latest after this time span. If it remains passive the rele- The first two parts of this series of ar ticles addressed the topics of
vant LIN Slave sends another Wake Up Signal. The number of repeti- serial data exchange in the automobile and CAN. The next two ar ti-
tions and the inter val between repetitions, as well as timeouts are cles will discuss the serial bus systems FlexRay and MOST.
defined in the specification.
Literature and links:
In case of networking issues: Quick resolution with exter- [1] www.lin-subbus.org
[2] LIN Specification Package Revision 2.1
nal expertise [3] Road vehicles – Diagnostics on Controller Area Network (CAN) – Part 2:
In networking with LIN, CAN, FlexRay and MOST, Vector Informatik Network layer services, International Standard ISO 15765-2.4, Issue 4,
[6] supports automotive OEMs and suppliers with a universal tool 2002-06-21
chain, embedded software components, base software for AUTOSAR [4] Road vehicles – Diagnostics on controller area network (CAN) – Part 3:
control modules and hardware inter faces. Users of the CANoe.LIN Implementation of diagnostic services, International Standard ISO
15765-3.5, Issue 5, 2002-12-12
tool for example benefit over the entire development process from
[5] Road vehicles – Diagnostic systems – Part 1: Diagnostic services, Inter-
practice-proven functions for model generation, simulation, func- national Standard ISO 14229-1.6, Issue 6, 2001-02-22
tional testing, conformity testing, diagnostics and analysis. Multi- [6] www.vector-informatik.com
bus design and maintenance of the communication data of a net- [7] www.vector-academy.com
worked system is supported by DaVinci Network Designer for LIN,
CAN and FlexRay for example. Development, calibration and diag-
nostic tools for in-vehicle ECUs complete Vector’s 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 train-
ing program cover ing Vector tools, software components and serial
bus systems.
For an entry-level introduction to serial data exchange in the auto-
mobile the Vector Academy [7] of fers the one-day training course
“Serial bus systems in the automobile”. Training courses on CAN,

Eugen Mayer
(Graduate Engineer with Technical Teaching
Cer tif icate), after completing his vocational
training to become a communications tech-
nician, studied electronics at the Technical
College in Ravensburg/Weingar ten, Germa-
ny, 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,
Figure 5: Fax +49-711/80670-111,
Communication state model of a LIN Slave. E-Mail: eugen.mayer@vector-informatik.de

1/16
03 Press Book_Seite_1-12_1-17:Press Report 2 09.02.2010 13:08 Uhr Seite 6

1/17
04 Press Book_Seite_1-18_1-21:Press Report 4 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 siderably simplifies the code development process. Since LIN sup-
improvements were made with the LIN 2.1 protocol version released ports only “unsigned signals”, globally defined signals must also be
in November 2006 for event-triggered frames, Slave identification unsigned. This limitation can usually be accepted by the CAN net-
and Slave configuration as well as for diagnostics over LIN users are works.
now awaiting the LIN consor tium’s release of LIN 2.1 conformance
test specification in the second quar ter of 2008. This document Without the appropriate tool support for network design, it is very
specifies tests for validating the conformance of LIN devices ac- dif ficult to consider all design and quality requirements. Extensive
cording to the dif ferent parts of the LIN 2.1 specification. experience acquired dur ing series projects for var ious OEMs has
contributed to the success of version 2.0 of the DaVinci Network
LIN Network Design Designer LIN (Figure 2). For example, initial schedule tables can be
Prior to the development and test phases, many network design automatically generated by simply defining the frame cycle times.
challenges must first be mastered. These range from defining the The schedule timings can then be easily optimized and refined de-
system topology and cycle times to creating LIN frames and sched- pending on, for example, the per formance of each LIN Slave. The
ule tables as well as routing relationships with other bus systems. design tool from Vector also helps the user to implement design
LIN communication design needs to be completely error-free and rules such as naming conventions for meaningful identifiers and
consistent, since the resulting LIN Description File (LDF) is used for signal types as well as for uniform encoding of physical parameters.
all subsequent development steps: embedded software generation,
network analysis, conformance testing, system and integration
tests, etc. (Figure 1).

The choice of network topology depends on var ious factors. For ex-
ample, 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 OEM’s supplier.

Ef ficient Design across Networks


Network design can be signif icantly simplified by directly routing
signals between networks. This requires defining unique signal Figure 1:
names for both CAN and LIN signals. Using this routing method, the Typical workflow for LIN network design
ECU’s application code is relieved of routing tasks, which also con-

1/18
04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 2

Design elements can be easily reused, and consistency checks are used for simulation and ver ification are exclusively ECU external in-
automatically per formed. Especially impor tant for the ef ficient ter faces. White or gray box tests, on the other hand, always require
network design across bus systems is the uniform management of access to internal ECU inter faces. The Slave conformance test pro-
all signals in a global signal pool. DaVinci Network Designer is capa- vided with the development and test tool CANoe.LIN (Figure 3) is
ble of importing existing network descriptions via standardized implemented almost entirely as a black box test. The Master con-
data exchange formats such as LDF, NCF, DBC or FIBEX. This avoids formance test, on the other hand, is implemented a gray box test
in many cases the re-enter ing of signal and encoding def initions. 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
From Multibus Tool to Data Backbone is used for ver ification.
A future trend is the increasing movement towards global network
design across CAN, LIN, MOST and FlexRay bus systems. The central Prototype of a Black Box Master Conformance Test
management of all data and information at the vehicle or model Although a gray box implementation allows the Master conform-
level is becoming indispensable. Multibus design tools not only re- ance test to be fully automated, it can only be applied a the start of
quire access to a common, global signal pool, but must also support the V-model development process. This is mainly because the re-
multiple user access and rights. The eASEE Tool Suite from Vector quired test LDF and test application are not identical to real LDF
provides a data backbone that not only manages all engineer ing and application of the Master ECU. On request of an OEM, the LIN
data for network designs, but can also support the management of specialists from Vector have specified a prototype black box Master
project plans, storage of test data, coordinated data maintenance conformance test. By extending the Master driver to provide elev-
or archiving of defined version states before delivery to partner en test services, it was proved possible to per form the current
companies. LIN2.0 Master conformance test dur ing all phases of development
using the real LDF and application. The Vector concept is not only
Test Strategies 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 imple-
mentation 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
04 Press Book_Seite_1-18_1-21:Press Report 4 09.02.2010 13:09 Uhr Seite 3

OEM-standardized LIN-Portfolio Gavin C. Rogers


Last year, Audi, BMW, Daimler, Porsche and VW created a document (B.Eng M.Sc.) is team leader and product
for suppliers, which describes the requirements for the develop- manager for LIN development and test tools.
ment 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 Vector’s LIN Symposium. The main objective of this
initiative is to reduce development and production costs through
maximum reusability. The standardization of the physical layer re-
quirements across dif ferent OEMs does not end with the choice of
Hans Quecke
transceiver, but must also include specifications for connectors, fil- (Information Technology degree) is team
ter circuits, operating and installation conditions. A current exam- leader and product manager for tools used
ple for such a LIN device, is an intelligent battery sensor developed to design network architectures and commu-
nication data.
for several OEMs. A wiper motor and mirror adjuster are also in de-
velopment. In order to increase the size of the “LIN portfolio”, each
OEM developing a LIN device in cooperation with a supplier, harmo-
nizes the specifications with other OEMs in technical committees.

Figure 3:
Using the Slave Conformance Test
Module, LIN conformance tests can
be easily integrated into your own
CANoe test configurations.

1/20
04 Press Book_Seite_1-18_1-21:Press Report 4 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! N
he LI
y of t
r ve a cop t n ow!
Visit us at: www.lin-solutions.com Res e Cha r
ence s.com
Refer ution
w . l i n l
- s o
ww

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. 07 11 / 8 06 70-0
www.vector-informatik.com
05 Press Book_Seite_1-22_1-25:Press Report 4 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) compo-
nents used in automotive developments, ef ficient test
strategies for this cost-ef ficient bus system are gain-
ing 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 well-
known development and simulation tool
CANoe.LIN.

Introduction case. White box tests on the other hand always require access to
The LIN consor tium provides in addition to the specifications for a device’s internal inter faces (e.g. the LIN driver’s standardized
each the protocol version corresponding conformance test specifi- inter face). A LIN Master ECU of fers a very limited number of stimu-
cations. The LIN conformance tests are used to ver ify whether a LIN lation options via its external inter faces such as CAN. Gray box tests
device is conform to a specif ic protocol version and also serve as a that combine the two test methods are therefore the most com-
basis for the LIN accreditation. Since LIN networks operate accord- monly used method use to realize a LIN Master conformance test,
ing to the Master-Slave principle, the protocol conformity of a Mas- Figure 1.
ter node is of utmost impor tance. The LIN conformance tests are
specified separately for each OSI layer: physical layer, data link lay- Test Environment for LIN Conformance Tests
er, network management and node configuration. Only application A typical ECU test case requires configuration and initialization
layer tests need to be specified by the OEM or supplier. of the test system and ECU under test, as well as subsequent
stimulation and ver ification. The Slave conformance tests provided
Black box tests are best suited for the methodical implementation with CANoe.LIN from Vector are implemented almost entirely as
of conformance tests, since they exclusively use a device’s external black box tests. The tester in its role as LIN Master can usually
inter faces (e.g. LIN inter face) to stimulate and ver ify each test 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
05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 2

Only a few tests require manual stimulation or ver ification e.g. in and generation of the Master driver code according to the test LDF,
order to stimulate a wakeup signal. The Master conformance test, before the Master-ECU can be tested.
on the other hand, is implemented by the Stuttgart-based tool
provider as a gray box. A special test LIN Description File (LDF) is The gray box Master conformance test allows the Master driver in-
provided to ensure the correct configuration of the Master driver. ter face to be indirectly accessed by the LIN-bus via a test applica-
Together the generated driver code a special test application must tion. Although full test coverage can be achieved in this way, this
be downloaded to the Master under test. In this way, the LIN bus approach means that the usual V-model development process can-
can be used for both stimulation and ver ification purposes, despite not be strictly followed. For example, it is only possible to ver ify
the tester’s role as LIN Slave. the Master’s conformity at the beginning of the development pro-
cess. As soon as the productive database (LDF) and application are
The Delphi Technical Center in Krakau, Poland, has gained consider- running on the Master ECU, fur ther ver ifications can no longer be
able experience with CANoe.LIN in the field of testing for both easily per formed. Fur thermore, the OEM can not repeat the Master
LIN2.0 and J2602, the U.S. version of LIN. Since the LIN conform- conformance test without assistance from supplier.
ance tests do not cover the OSI application layer, Delphi TCK has
extended their test activities to cover var ious application tests. The The Way to a Black Box Master Test
main focus of these tests is to test: signals, schedule tables, gate- Consequently, many automotive OEMs and suppliers of ten ask
way routings, and diagnostics. The CAPL test functions provided whether the Master conformance test can be implemented as a
with CANoe.LIN have proved to be indispensable in implementing black box test. This would have the big advantage that OEMs and
and automating such tests. According to Delphi TCK even very com- suppliers could independently per form tests dur ing the entire de-
plex test cases were easy to implement and extend using the C-like velopment process with minimal configuration ef fort.
CAPL syntax.
However, in order for a black box Master conformance test to have
Disadvantages of Gray Box Master Tests genuine advantages over a gray box test, cer tain requirements
With respect to usability, a gray box implementation of the Master must be first met. Probably the most impor tant one is that the
conformance test has several disadvantages. For example it is not same driver software used for development must also be used for
possible to per form this test dur ing all phases of development. tests. One way of achieving this is to extend the LIN Master driver
Fur thermore, some preparation ef fort is involved, e.g. configuration 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
05 Press Book_Seite_1-22_1-25:Press Report 4 09.02.2010 13:15 Uhr Seite 3

This driver extension must permit the direct stimulation and ver ifi- Master’s normal application. A completely independent and parallel
cation of the Master under test via the LIN bus by providing the operation of both test and application proved to be impossible. The
tester with special test services, e.g. to change the schedule table application must therefore be involved in the realization.
or read the driver’s status word. The test communication over the
LIN bus between Master and tester can use a special diagnostic There are basically two possible strategies for handling the interac-
service, comparable to those used for reconfiguration services. tion between the application and the driver’s test mode, Figure 3.
A fur ther requirement on such a driver extension is of course the One way is clearly inform the application that a test is being execut-
minimal increase in ECU resources. The test inter face should also be ed. An alternative method is to hide the test execution from the ap-
removable from the productive code, e.g. via a preprocessor define. plication as far as possible. Both strategies have their advantages
and disadvantages. The final choice of strategy may depend on the
Prototype of a Black Box Test for LIN 2.x feedback and wishes of Master-ECU suppliers. In both cases existing
The LIN specialists at Vector were requested by an OEM to design drivers need to be extended to support the required test services.
and specify a black box Master conformance test. Dur ing specifica- The additional code required for the test-server functionality has
tion of the prototype, it became quickly clear that the test commu- been estimated to be 20–30 % of current LIN2.x drivers and can be
nication must not negatively af fect the normal operation of the considered unproblematic for most Master ECU projects.
Master-ECU. This can be only achieved by applying the standard LIN
diagnostics consisting of Master Requests and Slave Responses us- The current prototype implementation provides eleven services,
ing a new special diagnostic service. Only in this case, it is the test- which is more than suf ficient to satisfy the LIN 2.0 Master conform-
er as Slave and not the Master who initiates communication. The ance test, Figure 4. The proposed concept from Vector is not only
tester sends a test command to the Master-ECU, which can respond extendable, but can also be easily standardized, since it is based on
either positively or negatively, Figure 2. the existing LIN development process and protocol specifications.

Before sending each test command it is necessary to execute a test Apart from these activities, Vector plans to fur ther develop
log-in and a test initialization. This raises the question to which ex- CANoe.LIN. For example, support of LIN 2.1 Slave tests is planned
tent a conformance test can be implemented independently of the 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
05 Press Book_Seite_1-22_1-25:Press Report 4 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 Gavin C. Rogers
B.Eng M.Sc., is team leader and product
expected with Release 7.1 of CANoe.LIN in the fourth quar ter of manager for LIN development and test tools.
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 experi-
ence and expertise at Vector.

Figure 4:
An over view of the 11 test
commands, which allow a com-
plete coverage of the cur rent
LIN2.0 Master conformance
test.

1/25
06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 1

Serial Bus Systems in the Automobile

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 be-
tween the central control module and the four satellite ECUs, one
located at each shock absorber. This ar ticle traces FlexRay’s path
into the automobile and explains the key principles of FlexRay bus
technology.

According to the German Federal Statistics Of fice [1] driving on mentations require very high data rates to transmit the increasing
Germany’s roads was never so safe as in the year 2005. Although number of control and status signals. They are signals that not only
vehicle registrations grew considerably, there was a nearly one per- need to be transmitted extremely quickly; their transmission also
cent reduction in accidents involving personal injury (336619) com- needs to be absolutely deterministic.
pared to the prior year. There were also signif icant reductions in That is the reason for the growing impor tance of communication
the number of traf fic deaths (5361, -8.2%), serious injuries systems that guarantee fast and deterministic data transmission in
(76952, -4.6%) and minor injuries (356491, -1 %). This trend was the automobile. Potential use of by-wire systems fur ther requires
continued in 2006: Between January and August, 3260 traf fic par - the design of fault-tolerant structures and mechanisms. Although
ticipants were killed, and this represents a 7.8 percent reduction by-wire systems may of fer wide-ranging capabilities and the bene-
compared to the prior year. The number of injured dropped by 5.8 fits of increased design freedom, simplified assembly, personaliza-
percent over the same time period. tion of the vehicle, etc., data transmission requirements in the au-
tomobile are elevated considerably, because these systems belong
Decisive in lower ing the number of accidents and reducing the se- to the class of fail-operational systems. They must continue to op-
ver ity of accident outcomes are active safety systems and assist- erate acceptably even when an error occurs.
ance systems that support drivers in their task of driving the vehi-
cle. One study by a number of well-known automotive OEMs sho- CAN cannot satisfy these requires due to its event-driven and prior -
wed, for example, that ESP reduced the number of skidding acci- ity-driven bus access, its limited bandwidth of 500 KBit/sec based
dents by up to 80 % [2]. Making just as impor tant a contribution to on physical constraints in the automobile, and lack of fault-toler-
reducing the sever ity of accident outcomes are increasingly safer ant structures and mechanisms [3].
passenger cells and optimized restraint systems.
FlexRay – The answer to heightened data transmission re-
In light of the goal of halving traf fic fatalities by the year 2010, the quirements in the automobile
automotive industry is focusing on fur ther developing existing ac- The cer tainty that CAN could hardly be expected to satisfy growing
tive safety systems and driver assistance systems and developing data transmission requirements in the automobile over the mid-
new innovative systems. Since these systems not only provide in- term, led to the development of a number of deterministic and
formation and instructions, but of ten also make corrective inter - fault-tolerant serial bus systems with far greater data rates than
ventions and assume driving tasks, it is no longer possible to do CAN. Examples include: TTP (Time Triggered Protocol) [4], Byte-
without electronic inter faces to the chassis and drivetrain. The flight [5] and TTCAN (Time Triggered CAN) [6]. Although a develop-
combination of brake-by-wire and steer-by-wire systems is thought ment partnership was created as early as 2001 between Audi and
to have great potential. the TTP promoting company TTTech, and although Byteflight was
successfully applied to BMW 7-series cars in 2001, it is FlexRay that
Requirements of future data transmission in the automobile has prevailed in the automotive industry.
Implementations of ever more challenging safety and driver-assist-
ance functions go hand in hand with the increasingly more inten- An impor tant reason for the success of FlexRay was the founding of
sive integration of electronic ECUs in the automobile. These imple- the FlexRay Consor tium [7], under whose auspices the two motor

1/26
06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 2

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

Today the FlexRay Consor tium is made up of seven “core partners”: Time-triggered communication not only ensures deterministic data
BMW, Bosch, DaimlerChrysler, Freescale, General Motors, Philips communication; it also ensures that all nodes of a FlexRay cluster
and Volkswagen. Gradually, a number of Premium Associate Mem- can be developed and tested independent of one another. In addi-
bers (including Vector Informatik [8]) and Associate Members joi- tion, removal or addition of FlexRay nodes in an existing cluster
ned the organization. must not impact the communication process; this is consistent with
the goal of re-use that is of ten pursued in automotive develop-
Making a signif icant contribution to the success of FlexRay was the ment.
detailed documentation of the FlexRay specification. The two most
impor tant specifications, the communication protocol and the Following the paradigms of time-triggered communication archi-
physical layer, are currently in Version 2.1. These and other FlexRay tectures, the underlying logic of FlexRay communication consists of
bus technology specifications can be downloaded from the home- trigger ing all system activities when specif ic points are reached in
page of the FlexRay Consor tium [7]. the time cycle. The network-wide synchronism of FlexRay nodes
that is necessary here, is assured by a distributed, fault-tolerant
FlexRay communication architecture – Time-triggered, clock synchronization mechanism: All FlexRay nodes not only con-
fault tolerant and flexible tinuously correct for the beginning times (offset correction) of regu-
Just as in the case of data communication in a CAN cluster, data larly transmitted synchronization messages; they also correct for the
communication in a FlexRay cluster is also based on a multi-master duration (slope correction) of the communication cycles (Figure 2).

Figure 1:
Principle of FlexRay
communication.

1/27
06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 3

This increases both the bandwidth ef ficiency and robustness of the FlexRay communication: Deterministic and dynamic
synchronization. Each communication cycle is equal in length and is essentially orga-
nized into a static time segment and a dynamic time segment (Fig-
FlexRay communication can be based on either an electrical or opti- ure 1). Of central impor tance here is the static segment that begins
cal physical layer. Speaking in favor of electrical signal transmis- each communication cycle. It is subdivided into a user-definable
sion is its simplicity, which brings cost advantages. The compara- number (maximum 1023) of equally long static slots.
tively cost-intensive optical signal transmission is character ized by
substantially better electromagnetic compatibility (EMC) compared Each static slot is assigned to a FlexRay message to be sent by a
to electrical signal transmission. FlexRay node. Assignments of static slots, FlexRay messages and
FlexRay nodes are made by slot number, message identifier (ID),
FlexRay communication is not bound by a specif ic topology. A sim- and the value of the slot counter implemented on each FlexRay
ple, passive bus structure is just as feasible as an active star topolo- node. To ensure that all FlexRay messages are transmitted at the
gy or a combination of the two (Figure 3). The primary advantages right time and in the correct sequence in each cycle, the slot coun-
of the active star topology lie in possibility of disconnecting faulty ters on all FlexRay nodes are incremented synchronously at the be-
communication branches or FlexRay nodes and - in designing larger ginning of each static slot. Because of its guaranteed equidistant
clusters - the ability to terminate with ideal bus terminations when and therefore deterministic data transmission, the static segment
physical signal transmission is electrical. is predestined for the transmission of real-time relevant messages.

To minimize failure risk, FlexRay of fers redundant layout of the Following the static segment is an optional dynamic segment that
communication channel (Figure 4). This redundant communication has the same length in every communication cycle. This segment is
channel could, on the other hand, be used to increase the data rate also organized into slots, but not static slots, rather so-called min-
to 20 Mbit/sec. The choice between fault tolerance and additional islots (Figure 1). Communication in the dynamic segment (mini-
bandwidth can be made individually for each FlexRay message. slotting) is also based on allocations and synchronous increment-
ing of the slot counters on the FlexRay nodes.
Finally, an independent control mechanism (Bus Guardian) ensures
that a FlexRay node only gets access to the bus dur ing its turn in However, it is not mandatory to transmit the FlexRay messages as-
the communication cycle. This prevents bus monopolization by a sociated to the minislots with each communication cycle, rather
defective FlexRay node (babbling idiot). they are only sent as needed. If messages are not needed, the slot

Figure 2: Figure 3:
Clock synchronization. Combined topology of passive bus and active star.

1/28
06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:16 Uhr Seite 4

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

counter of a minislot is incremented after the defined time period. CRC-protected data transmission
While a (dynamic) FlexRay message is being transmitted, incre- The signals in a FlexRay cluster are transmitted by the well-defined
menting of the slot counter is delayed by the message transmission FlexRay message, wherein there is essentially no dif ference in the
time (Figure 5). formats of the FlexRay messages transmitted in the static segment
and those transmitted in the dynamic segment. They are each com-
The allocation of a dynamic FlexRay message to a minislot implicitly posed of a header, payload and trailer (Figure 6).
defines the prior ity of the FlexRay message: The lower the number
of the minislot, the higher the prior ity of the dynamic FlexRay mes- The header comprises the five-bit wide status field, ID, payload
sage, the earlier it will be transmitted, and the higher the probabil- length and cycle counter. The header-CRC (11 bits) protects parts of
ity of transmission given a limited dynamic time segment length. the status field, ID and payload length with a Hamming distance of
The dynamic FlexRay message assigned to the first minislot is al- 6. The ID identifies the FlexRay message and represents a slot in
ways transmitted as necessary, provided that there is a suf ficiently the static or dynamic segment. In the dynamic segment the ID cor-
long dynamic time segment. responds to the prior ity of the FlexRay message. The individual bits
of the status field specify the FlexRay message more precisely. For
In the communication design it must be ensured that the lowest example, the “sync frame indicator bit” indicates whether the Flex-
prior ity dynamic FlexRay message can be transmitted too – at least Ray message may be used for clock synchronization.
provided that there are no other, higher prior ity needs. The design-
er of a FlexRay cluster must also ensure that transmission of the After the header comes the so-called payload. A total of up to 254
longest dynamic FlexRay message is even possible. Other wise, the useful bytes may be transported by one FlexRay message. The trail-
communication design would not make any sense. er encompasses the header and payload-protecting CRC (24 bit).
Given a payload of up to 248 useful bytes, the CRC guarantees a
The communication cycle is completed by two additional time seg- Hamming distance of 6. For a larger payload the Hamming distance
ments (Figure 1). The “Symbol Window” segment serves to check is 4 [8].
the functionality of the Bus Guardian, and the “Network Idle Time –
NIT” time segment closes the communication cycle. Dur ing the NIT In networking issues: Achieving objectives rapidly with
the FlexRay nodes calculate the correction factors needed to syn- external expertise
chronize their local clocks. At the end of the NIT, an offset correc- In the year 2001, Vector Informatik was already of fer ing the first
tion is made if necessary (the slope correction is always distributed product solution for the development of FlexRay systems. In the
over the entire communication cycle). There is no data transmission meantime, developers can now obtain a comprehensive portfolio of
dur ing the NIT. products [9]. These include tools for designing, developing, simu-
lating, analyzing, testing and calibrating ECUs and distributed net-
works. 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 multi-
bus concept enables simultaneous operation of FlexRay, CAN, LIN
and MOST bus systems. For precise study of the FlexRay network’s
system behavior in response to errors and disturbances, FRstress
generates them on a channel in the FlexRay cluster. For direct ac-
cess to internal ECU var iables, the developer needs a special meas-
urement and calibration protocol: XCP on FlexRay. In the context of
the development of the active chassis system on the new BMW X5,
Figure 4: BMW engineers implemented Vector’s measurement, calibration
Passive bus structure with two communication chan- and diagnostic tool CANape. As the XCP-on-FlexRay Master, CANape
nels minimizes failure risk. measures and calibrates individual ECU parameters directly via
FlexRay. Besides software, Vector also develops stacks for ECUs.

1/29
06 Press Book_Seite_1-26_1-31:Press Report 2 09.02.2010 13:17 Uhr Seite 5

FlexRay software components make it possible to interconnect ap-


plications with dif ferent bus or operating systems in an uncompli- Eugen Mayer
(Graduate Engineer with Technical Teaching
cated way. For hardware access to FlexRay buses, suitable bus in- Cer tif icate), after completing his vocational
ter faces connect to the USB, PCI and PCMCIA ports of a PC or note- training to become a communications tech-
book computer. nician, studied electronics at the Technical
College in Ravensburg/Weingar ten, Germa-
The Vector Academy [10] can teach the basic knowledge needed to
ny, and studied electrical engineer ing and
quickly become familiar with the diverse development activities re- vocational teaching at the University of
lated to ECU communication in the automobile. This knowledge is Stuttgart. Since 1999 he has been working at
Vector Informatik where he is employed as a
shared in the context of seminars on CAN, LIN, FlexRay and MOST.
Senior Trainer.
Tel. +49-711/80670-574,
Literature and links: Fax +49-711/80670-111,
[1] www.destatis.de [2] www.bosch.com E-Mail: eugen.mayer@vector-informatik.de
[3] Mayer, E.: Datenkommunikation im Automobil – Teil 2: Sicherer Daten-
austausch mit CAN im Automobil [“Data communication in the automo-
bile – 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

Figure 5:
Example of communi-
cation flow in the dy-
namic time segment.

Figure 6:
Structure of the
FlexRay message with
header, payload and
trailer.

1/30
06 Press Book_Seite_1-26_1-31:Press Report 2 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 Vector’s 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.

nce
Get on board: www.flexray-solutions.com efere
Fle x Ray R
he now!
Get t
Char t ions.
com
r ay - solut
.f le x
www

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart, Germany
Tel. +49 (0) 7 11 / 8 06 70-0
www.vector-informatik.com
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.

As a scalable high-speed communication system with deterministic > Interrupt Services Routines (ISRs) are hardware-specific and
behavior, FlexRay is the right solution for use as a data backbone, are triggered by the hardware periphery. They have higher
for distributed control systems or for safety-relevant applications priority than tasks and should therefore only be reserved
in the automotive area. In contrast to event-triggered CAN commu- for subtasks requiring the fastest possible reaction time.
nication, all messages are assigned to fixed communication inter-
vals. This offers to each participating ECU a cleary timed availabili- In a time-triggered operating system all processes and actions
ty of its data. The design of a FlexRay network requires that certain under the control of the operating system are solely depending on
fundamental parameters be defined for all participating network the time. For the application this results in strictly deterministic
nodes in a very early phase of development. These parameters time behavior.
include baudrate, cycle length, number and length of the slots in
the static and dynamic segments or macrotick duration. This sched- AUTOSAR OS
uling of communication processes is mapped in the communica-
tion-specific software components, but it can also influence the AUTOSAR has taken the OSEK-OS as a basis and extended it to
time structure of the application software. enable support of time-triggered functionalities. The specific prop-
The operating system (OS) coordinates the interplay of all par- erties of the AUTOSAR OS [2] are provided in four expansion stages,
ticipating software components. Both event-triggered and time- the so-called Scalability Classes (SC). Table 1 shows a summary of
triggered operating systems are commercially available, each one the relationship between these properties and the Scalability
having different services. Another available option is operating Classes. Only properties relevant to a FlexRay-based application are
systems with memory protection. listed. These properties are explained in the following.
Which operating system is best suited to a FlexRay-based appli-
Memory Protection

cation, and how should it be configured? In particular the question


Time Monitoring

Synchronization
Schedule Tables

arises of whether a time-triggered operating system is absolutely


Global Time/

necessary for synchronized FlexRay communication.

Scalabilty
Fundamentals of event-triggered and time-triggered
Class Comment
operating systems
SC1 Event-triggered
Advanced development
Until now, event-triggered operating systems have usually been SC2
of OSEKtime
used in the automotive area. The broadest acceptance is enjoyed by
Advanced development
the OSEK/VDX [1] OS, which in the future will also be available in SC3
of HIS-Protected OS
the form of an ISO standard. The goal of an operating system is to
SC4
provide, under optimal utilization of the hardware used, a supple-
mental run-time environment for managing functional units. Table 1: FlexRay-relevant properties of the AUTOSAR OS
Defined operating system services offer this functionality. In
designing an application, at first time-independent, concurrent The currently available specifications of BSW (Basic Software) and
subtasks are defined. The outcome of this are tasks or interrupts RTE (Runtime Environment) do not cover memory protection yet.
compete for run-time assignment according to the operating sys- This will be addressed in future versions of the BSW and RTE
tem’s scheduling algorithm: specifications.
> 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.

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 budget, time monitoring guarantees lower-priority tasks or inter-


rupts access to the processor to execute their tasks.
The operating system manages multiple schedule tables. Each If an interrupt lasts too long, as in Case C of Figure 3, it is can-
schedule table consists of a list of defined time-based actions that celled so that the extended task can continue to execute.
either activate tasks or send events to tasks.
For each task: For each interrupt:
Time monitoring
> Timeframe: Monitoring time > Timeframe: See Task
In a real-time system what is important is to process all tasks at the period (greater than the > Worst case execution time per
right times. In the design phase sub-tasks are allocated fixed time execution time; it is not execution
windows. To avoid delays at runtime a task may not tie up the CPU absolutely essential that the > Max. number of interrupts per
longer than specified in the design. Therefore the operating system task be completed within the Timeframe
monitors the execution time of each individual task and each inter- monitoring time period; cf.
rupt. OSEKtime [3] provides classic deadline monitoring for this Figure 1 Case A).
purpose: Tasks must be completed before their assigned deadlines. > Execution time budget:
If a violation occurs, the overall system triggers a reset. This type Worst case execution time per
of monitoring is inadequate for extended tasks that can wait for monitoring time period.
events. That is why the AUTOSAR-OS working group has defined
execution time monitoring for each individual task and each inter- If multiple activation of a Basic Multiple interrupts may be
rupt. This monitoring is defined by various parameters in the Task should be allowed in the allowed per Timeframe. Howev-
configurator. operating system’s configura- er the worst case execution time
When a monitoring parameter is violated, depending on the con- tor, the execution budget con- only refers to a single loop pass.
figuration the operating system initiates a “Reset_OS”, “Kill_Appli- tains the total execution time The effect of an additional
cation”, “Kill_Task” or “Kill_Interrupt” as a reaction to the error. of all activations of the affect- interrupt per Timeframe is
Figures 1–3 represent an AUTOSAR OS Scalability Class 2 with ed task. In principle multiple shown in cases B and C of fig-
time monitoring tasks and interrupts. activations are not possible for ures 2 and 3.
Figure 1 shows the the monitoring of an application consisting extended tasks.
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 Fig-
ure 2. This exclusively affects the originator. According to the

1/33

07 Press Book_Seite_1-32_1-37.indd 3 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 software modules from different producers are integrated in an ECU
the different software packets can be separated at runtime in terms
Distributed control systems requiring synchronization of tasks of their memory areas. A processor with hardware support is also
beyond ECU boundaries need the support of a global time provided necessary. In addition, it should have a large memory and high
to the operating system on a regular basis. An application may syn- processing speed, since memory protection mechanisms slow down
chronize to the global time either: operating system services by a factor of 1.5 to 2 on average.
> Stepwise, as soon as the global time is made available and
according to the maximum adaptation step from the Process of data exchange between FlexRay bus and
configuration (“smooth”), or application
> By complete adaptation in one step (“hard”).
Any of the four AUTOSAR-OS properties presented may be selected,
Memory Protection and their costs and benefits must be weighed against one another
from a production implementation point of view. Thereby consider-
Mechanisms for memory protection are necessary for early detec- ation must be given to the OS for optimal support of the synchroni-
tion and prevention of disturbances by other modules. When zation 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

07 Press Book_Seite_1-32_1-37.indd 4 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 the application needs and the availability of the operating system
form a continuously repeating round. Each base cycle contains properties. In principle, communication tasks should be triggered
frames with different process data or signals for different applica- by the CC’s FlexRay timer. Activation of application tasks, on the
tion tasks. With its global time the FlexRay protocol provides the other hand, could be triggered by any desired timers. Four solution
foundation for synchronized data exchange. As soon as the data approaches are explained in the following:
network has been synchronized this global time is available to Solution A – Alarms attached to the OS System Timer trigger the
every Communication Controller (CC) in the network. application tasks.
In a distributed control system a function is distributed among At the beginning of each base cycle the “FlexRay Cycle Start
multiple ECUs in a network. The dead time caused by the signal Interrupt” is triggered by the FlexRay controller. The communica-
propagation time from the sending application to the receiving tion task is activated immediately. Independently, the operating
application can have a decisive influence on the quality of control. system timer initiates the sequence of application tasks. Figure 4
In principle, a small dead time has a beneficial effect. shows a simplified form of this solution approach with just one
In event-triggered communication systems the exchange of data application and one communication task. It should be noted that
between CC and Host is essentially interrupt-driven, and accessing later triggering of a Cycle Start Interrupt, e.g. caused by drift
to the bus may result under some conditions in wait times. The sig- between the CC oscillator and the Host oscillator, results in delayed
nal propagation time cannot be predicted precisely; therefore a processing of the transported FlexRay data (e.g. from frame 2) of
worst case estimate is typically made. Not until a network-global max. ∆tOS = 1 ms. If the application does not expect a quicker reac-
time of the FlexRay protocol is made available can the operating tion time, an OSEK-OS is sufficient.
system offer services for synchronization to this time. Via the TDMA Solution B – If the control system requires a shorter response
(Time Division Multiple Access) method all participating ECUs are time (less than 1 ms), triggering of the application task requires a
aware of the precise point in time each message is sent or received High Resolution Timer (resolution approx. 10 microseconds) with
in the static area of the FlexRay cycle. These two properties mini- the OSEK-OS. A suitable timer is then needed.
mize imprecision with regard to the signal propagation time of a Solution C – If the ECU does not have a High Resolution Timer,
FlexRay-based application. the FlexRay timer can be additionally used to activate time-critical
For synchronizing the exchange of data in a FlexRay-based appli- application tasks. FlexRay-independent tasks can continue to be
cation various methods of resolution are possible, depending on attached to the OS System Timer.

Figure 4:
Solution A – Data exchange between
FlexRay and an application task with
OSEK-OS

1/35

07 Press Book_Seite_1-32_1-37.indd 5 09.02.2010 13:29:00 Uhr


In startup behavior it should be noted that the FlexRay timer, offers the developer the optimal operating system for all FlexRay
and consequently also the tasks that it activates, are unavailable applications: osCAN certified to the OSEK/VDX standard with or
until the FlexRay controller has synchronized to the network for the without High Resolution Timer or osCAN AUTOSAR that covers Scal-
first time. If synchronization is lost afterwards, the FlexRay timer ability Classes SC1-SC4 according to AUTOSAR OS V2.0. The Vector
can continue to operate based on its local time, provided that the FlexRay software components will operate together with any of
FlexRay controller was configured for this. An AUTOSAR OS of Scal- these OS variants. The osCAN TimingAnalyzer analyzes the sched-
ability Class 1 with schedule tables is sufficient for this purpose. ulability of tasks from a worst-case perspective.
This solution enables a control system distributed over multiple Vector supports the user with software components and individu-
ECUs, since the FlexRay global time assures synchronization alized service for universal development of FlexRay systems up to
between all ECUs. This solution approach is depicted in Figure 5. series production. Development is simplified by mature tools that
Solution D – If in the above cases it is also necessary to monitor are tuned to one another, like for instance DaVinci Network Design-
the execution time of tasks and interrupts, an AUTOSAR OS SC2 or er for all FlexRay-typical design tasks or CANoe.FlexRay 6.0 for sim-
SC4 is required. This prevents excessive execution times and ulation and stimulation of a network, integration tests and rest-of-
achieves time deterministic behavior. bus simulation as well as analysis of the finished FlexRay network.
CANape 6.0 is used to access to all internal parameters of the
Summary FlexRay ECU via the standardized measurement and XCP-on-FlexRay
calibration protocol. The FlexRay Evaluation Bundle provides for
A FlexRay-based application does not absolutely require a time- quick and flexible implementation of a FlexRay network. This inte-
triggered operating system. The choice of a suitable operating sys- grated environment of software components and tools also includes
tem should be made individually for each ECU under consideration a sample application for a FlexRay system with two nodes.
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

Figure 5:
Solution C – Data exchange between
FlexRay hardware and an application
task with AUTOSAR SC1 OS

1/36

07 Press Book_Seite_1-32_1-37.indd 6 09.02.2010 13:29:00 Uhr


THE OPTIMAL OPERATING SYSTEM FOR FLEXRAY-BASED APPLICATIONS

Pascale Morizur (Graduate Engineer)


Literature references:
studied Physics/Electronics at the Grande
[1] OSEK/VDX Operating System, Version 2.2.2, www.osek-vdx.org
Ecole ICPI in Lyon (France). After graduating
[2] AUTOSAR - Specification of Module Operating System V2.0, in 1986 she worked for 10 years at MAN com-
www.autosar.org mercial vehicles in advanced development
[3 OSEKtime – OSEK/VDX Time-Triggered Operating System, Version 1.0, for CAN, J1939 and diagnostics. She is
www.osek-vdx.org 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 Univer-
sity 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 Univer-
sity of Stuttgart. After working for 4 years
developing software for embedded control-
lers 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 commit-
tees 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

07 Press Book_Seite_1-32_1-37.indd 7 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 compo-
nents in an ECU. The ways in which today’s 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 vehicle models. The standard-conformant ECU-specific software is
starting line providing large transmission bandwidth for fast con- modularly structured (Figure 1). This enables partitioning of the
trol systems. FlexRay enables 20 times greater bandwidth than CAN software components above the RTE and the basic software below
and reduces complexity by using fewer gateways. Because of its the RTE. The basic software has a modular internal structure and is
time-triggered control, it is especially well suited as a communica- specified by clearly defined interfaces, so that software from any
tion system for distributed, fault-tolerant systems and safety-rele- source can be used in integration. In addition, the standard defines
vant applications. There is also the hope that the growing complex- which exchange formats can be used and how the interfaces
ity of vehicle electronics can be kept in check by standardization of between individual modules need to operate.
the software system architecture with AUTOSAR. This modularity makes it easier to scale software features to the
specific requirements of a vehicle variant or generation, e.g. ECUs
What does FlexRay ECU software need to look like? without network management. Development effort for the basic
software can be reduced for both OEMs and ECU suppliers because
To fully exploit the advantages of FlexRay-based communication, it the individual software modules can be delivered fully preconfig-
makes sense to fundamentally develop the associated basic soft- ured by the software supplier. This lets developers place greater
ware according to the AUTOSAR specification. AUTOSAR specifies a focus on innovations and the actual development of functions than
new development methodology, software architecture and basic was previously possible in development.
software. OEMs may gradually introduce it step-by-step on new

1/38

08 Press Book_Seite_1-38_1-41.indd 2 09.02.2010 13:25:59 Uhr


Embedded Architecture for FlexRay Network management handles the coordination of all ECUs in the
cluster with regard to communication needs for the bus system. If
The schematic layout of FlexRay basic software from Vector is all of the bus nodes no longer have communication needs, the syn-
depicted in Figure 2. FlexRay-specific components such as the chronous transition to the Bus Sleep ECU mode is initiated.
interface, driver, network management (NM), and transport proto- The FlexRay transport protocol is also placed on the FlexRay
col (TP) are all contained in the FlexRay stack. The driver abstracts interface. It handles the task of taking large data packets that can-
the hardware, making it possible to service different communica- not be sent in one PDU, breaking them down into segments, and
tion controllers (CC). The driver initializes the controller, sends and reassembling them on the receiving side.
receives frames and detects controller errors. The interface commu- Just how modular adaptation works in practice is demonstrated
nicates with the layers lying above it, processes PDUs (Protocol Data by the example of two FlexRay drivers for a FlexRay controller from
Units) into frames and works in the reverse direction too. Moreover, Freescale and from NEC. The driver is optimally adapted to the spe-
it issues send and receive acknowledgments to the affected layers. cific 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

08 Press Book_Seite_1-38_1-41.indd 3 09.02.2010 13:26:00 Uhr


providing the layer above it with an unchanged “view” and mode of that accesses measurement data in an address-oriented way, which
behavior. In the case of the 16-bit S12X controller from Freescale, are then acquired task-synchronously (event driven) in the ECUs.
the FlexRay driver must manage the buffer-RAM, since in this case
the necessary memory space must be swapped out to the system- Dynamic bandwidth management
RAM. The 32-bit NEC V850 controller already contains a large RAM
for the buffers in the FlexRay controller. This is where the driver A connection is established via an initial communication channel
performs its efficient partitioning and utilization. that is defined in the ECU description file (A2L). By transport layer
commands, the XCP Master controls allocation of available slots in
ECU calibration with XCP on FlexRay the dynamic section of a cycle and thereby enables channel exten-
sion for transmission of measurement and calibration data. This
It is even easy to integrate components developed at a later time in “load distribution” is performed dynamically at runtime for optimal
the architecture, e.g. components that became necessary because bandwidth utilization. Since multiple ECUs communicate over the
of new protocols or extended standards. These interfaces must also same bus, a slot cannot be assigned exclusively; rather so-called
conform to the AUTOSAR standard. For example, XCP functionality slot multiplexing makes it available to multiple ECUs. This makes
might be added to the previously described FlexRay stack in order sense if less bandwidth is needed for a measurement, e.g. if an ECU
to enable measurement and calibration of internal signals of the does not need to send a message each cycle. Each message gets a
FlexRay ECUs. unique address for this purpose (LPDU-Id, Data Link Layer Protocol
XCP is a universal communication protocol for optimizing the sys- Data Unit Identifier), which describes the slot, cycle and channel.
tem parameters of an ECU. Due to the separation of protocol layer This makes it possible to fill the same slot with data from a differ-
and transport layer, XCP can be operated in various types of com- ent ECU in each send cycle.
munication networks (XCP on CAN, FlexRay, Ethernet, USB, RS232 The measurement data are provided with a timestamp making it
or SPI/SCI). The clear separation of layers is also reflected in the possible to query measurement values at shorter intervals than the
integration in the FlexRay stack. The universal protocol layer XCP cycle time. For example, a measurement may occur every 2.5 ms, even
lies above the FlexRay-specific transport layer (FrXCP), which in if a system has a 5 ms cycle. It is only necessary to ensure that the
turn enables signal exchange with the FlexRay interface (Figure 3). bandwidth is sufficient to transmit the data within a required time.
Due to dynamic bandwidth allocation, the driver must handle the The ECU must reserve and dynamically configure transmission
additional task of buffer configuration during measurement or cali- and reception buffers by allocating RAM for this communication.
bration. Therefore, this module is replaced by an extended version The RAM may be located in the controller or it may be necessary to
of the standard AUTOSAR driver. use external memory managed by the FlexRay driver.
XCP is an address-oriented protocol. Communication takes place Just how many slots are available for XCP and how slots should
between a controller component and a similarly structured soft- be distributed must be defined early on – namely during system
ware component in the XCP Master. Generally, the XCP Master is a definition. This is done in the FIBEX file by also defining the slots
measurement and calibration tool (such as CANape from Vector) reserved for XCP. Various scenarios are possible here:

Figure 3:
Integration of XCP in the FlexRay
stack with clear separation of proto-
col layer (XCP) and transport layer
(FrXCP).

1/40

08 Press Book_Seite_1-38_1-41.indd 4 09.02.2010 13:26:01 Uhr


EMBEDDED SOFTWARE FOR FLEXRAY SYSTEMS

> Each ECU occupies its own slot


Dirk Großmann (Graduate Engineer)
> Multiple ECUs utilize the same slot studied electrical engineering at the Univer-
> In this case each ECU has its own address (NAX, Node Address sity of Stuttgart. Since 2003 he has been
for XCP). XCP transport layer commands are used to activate or employed as team leader responsible for the
development of FlexRay embedded software
deactivate the buffer components at Vector.
> Buffers are configurable, which corresponds to dynamic Tel. +49-711/80670-223,
allocation Fax +49-711/80670-111,
E-mail:
dirk.grossmann@vector-informatik.de
Regardless of the transport protocol used, the user interface of a
tool (XCP Master) should always represent the actual measurement
Oliver Kitt (Graduate Engineer)
and calibration task adequately. Applications engineers can then
studied physics at the University of Stutt-
optimally tune ECU parameters independent of the bus system used gart. As team leader he is responsible for the
for communication. development of measurement and calibra-
tion protocols in CANape.
The calibration engineer works with symbolic names, which allows
Tel. +49-711/80670-327,
the parameters and measurement variables to be found in the ECU Fax +49-711/80670-111,
without needing to know the encoded addresses of specific vari- E-mail: oliver.kitt@vector-informatik.de
ables. The calibration tool uses the ECU description file to come up
with the link between the name and the physical address (Figure 4).

Universal support in all development phases

The FlexRay developer gets universal support from the Vector com-
pany: From system description to implementation of the base soft-
ware 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, calibra-
tion 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 univer-
sal 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

08 Press Book_Seite_1-38_1-41.indd 5 09.02.2010 13:26:01 Uhr


09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 1

1 l AUTOMOTIVE 2007 l SPECIAL EDITION 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

FlexRay 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.

D
uring the development of FlexRay ECUs and so that other ECUs can integrate into the TDMA (Time Divi-
systems, engineers commonly encounter chal- sion Multiple Access) schedule. If the FlexRay communi-
lenging tasks such as startup simulation, ECU cation of a single non-startup/sync ECU is being tested,
tests and network simulation. This article describes how then the analysis tool needs to be able to simulate a Flex-
CANoe.FlexRay is already enabling FlexRay engineers Ray bus that has already started. CANoe.FlexRay can gene-
to efficiently perform these tasks in a routine way. rate two startup/sync frames in order to provide this type
of startup of a FlexRay bus. The startup phase of a cluster
Startup Simulation can be observed using the asynchronous mode of Vector’s
A synchronized bus is a major requirement for a FlexRay FlexRay interfaces VN3300 (PCI), VN3600 (USB) or VN7600
communication. Before the application can communicate, (USB with CAN interfaces). It is possible for example to
the bus must be started. During this startup phase the bus receive wakeup pattern, symbols, startup and normal fra-
is in an asynchronous mode until at least two ECUs have mes before the cluster is in synchronous mode. The bus
synchronized their FlexRay clocks and provide sync frames can also be analyzed in this mode without using a FIBEX
1/42
09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 2

S P E C I A L E D I T I O N F L E X R AY l AUTOMOTIVE 2007 l2
database. Only the baud rate is required in
order to initialize the bus interface. To star-
tup 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 syn-
chronous modes can also be combined so
that the interface changes its mode auto-
matically according to the clock synchroni-
zation state giving FlexRay engineers full
analysis and simulation features at all Figure 1: The FlexRay Frame Panel makes it easy to interactively send
times. FlexRay frames
© automotive
ECU Test by Stimulation
The easiest way of testing an ECU is to
send frames interactively using CANoe’s FlexRay Frame The Cluster Monitor can also be used in offline mode to
Panel. Using this integrated panel a FlexRay frame’s paylo- analyze log files. More extensive tests can be implemen-
ad (i.e. its signals) can be interactively modified during run- ted in the programming language CAPL (also for the offli-
time. Signals for all bus systems can be modified via user- ne analysis).
defined Control Panels. Using Signal Generators it is also
possible to change a signal’s value according to predefined ECU Test by Simulation
functions. For more advanced signal generation (e.g. arbi- In order to test the functional behavior of any real ECU, its
trary signal sequences or reactions to previous responses) environment must be simulated. The system or device
the programming language CAPL should be used. Using under test is usually embedded into a (Hardware-in-the-
the Test Feature Set of CANoe automated ECU tests can Loop) simulation. A minimal remaining bus simulation
be defined, executed, and reported. generates input frames and reacts to output frames from
the ECU under test. Optionally an environment model can
ECU Test by Observation be simulated, which generates sensor inputs and reacts to
During the development of any real ECU it is crucial to gua- actuator outputs. A simple example would be a model of a
rantee that the ECU communicates in conformance with discrete and interactive user panel. In more complex cases
FlexRay’s schedule table. Especially for frames in the sta- a quasi-continuous control algorithm (e.g. defined by Mat-
tic segment a periodically time-triggered transmission is lab/Simulink) may be executed under the control of CANoe.
assumed. CANoe can directly test and visualize whether Due to the time-triggered communication according to a
all expected frames (according to their Cycle Multiplexing) global FlexRay time, the algorithms for the simulated con-
of a specific ECU (sender) are on the bus. This feature is trollers and ECUs must be synchronized with the FlexRay
implemented in CANoe.FlexRay as the FlexRay Cluster schedule. The execution platform must therefore provide
Monitor. It helps engineers to identify the following: synchronization points, guarantee small latencies as well
as constant and minimal jitters. This guarantees to provide
Which nodes are online and sending? timely correct data updates on the bus. For the environ-
Are all specified frames sent by a specific node? ment or remaining bus simulation the execution platform
Are the frames sent in all scheduled cycles? must be deterministic. CANoe RT, along with its hardware
extensions RT Box and RT Rack, provides such a high per-
formance 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 inter-
faces. For both CANoe and CANoe RT the
same (simulation) models can be used.

Cluster Simulation
In the early design phases of a FlexRay
system it is important to test whether the
timings are correct and/or the performan-
ce of an ECU matches the communication
Figure 2: The Cluster Monitor for displaying the send conformity schedule. In other words, to check whet-
of FlexRay nodes and their messages her all frames can be received and trans-
© automotive mitted in the reserved time. The FlexRay
engineer therefore typically creates a (par-
1/43
09 Press Book_Seite_1-42_1-45:Press Report 3 09.02.2010 13:16 Uhr Seite 3

3 l AUTOMOTIVE 2007 l SPECIAL EDITION 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 chronously running clusters guarantee minimal delays bet-
to CANoe.FlexRay and by defining the nodes required for ween the signal occurrences on both buses.
the system under test. The CANoe.FlexRay’s features
allow the full bus load, which is generated by all ECUs of a Summary
cluster, to be simulated. The communication matrix and the All these application scenarios occur during the routine
FlexRay schedule in the FIBEX database are used to confi- work of engineers developing FlexRay products.
gure the simulation of all required ECUs. All frames are CANoe.FlexRay is a powerful tool to help engineers in their
automatically sent on the bus with default values. With Vec- everyday work when handling the new technical challen-
tor’s interfaces the theoretical maximum frame throughput ges of FlexRay buses. CANoe is the flagship of Vector’s
can be sent without running into resource problems (e.g. comprehensive portfolio of tools and embedded software
lack of send buffers). In this way all FlexRay ECUs can be components which are ready for both current and future
simulated using only one tool and one bus interface. FlexRay applications.
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
Gavin C. Rogers B.Eng. M.Sc. is Team
in order to simulate a power off node. In this case only a Manager in the “Tools for Networks and
wakeup pattern is received. Wakeup patterns can be sent Distributed Systems” product line.
in order to wake up a sleeping cluster. Using a special
extension to CANoe.FlexRay, any simulated node can par-
ticipate at the network management layer according to the
AUTOSAR-NM protocol.

Gateway Simulation
Dr. rer. nat. Carsten Böke is Senior Soft-
Gateways are used to transfer messages/frames/signals ware Development Engineer for the
between two or more buses. CAN/FlexRay-gateways are “Tools for Networks and Distributed
Systems” product line.
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 simu-
lating 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 © Carl Hanser Verlag, München 2007. All rights including
manipulating signals that are sent by the real ECUs. Optio- reprinting, photographic reproduction and translation
nally the two FlexRay clusters can be synchronized. Syn- reserved by the publishers.
1/44
09 Press Book_Seite_1-42_1-45:Press Report 3 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 Europe’s leading development part- A high-performance and flexible environment for complex
ners in the automotive and aerospace industries. About ECU tests over the FlexRay bus
5500 employees at 30 business sites in Europe and in the For conducting the simulation, Bertrandt uses CANoe.FlexRay
USA work on customized solutions ranging from indivi- together with CANoe RT and the Real Time Rack to implement
dual components and modules to complete systems and a high-performance test system for FlexRay:
vehicles. Testing an ECU with remaining bus simulation Ö Testing
is already possible in early development phases without
The Challenge requiring availability of real ECUs.
Using OEM-specific modules such as the Interaction Layer,
Testing FlexRay ECUs effectively and reproducibly
Transport Protocol, checksum calculation, etc. in the
Proper behavior of FlexRay ECUs in normal operation and
remaining bus simulation Ö Quick and easy implementa-
under fault conditions is to be tested beginning in early
tion of the remaining bus simulation and standardized
development phases. Test sequences of complex test cases
execution of OEM-specific functions.
need to be executed, but it must also be possible to manually
Execution of remaining bus simulation with CANoe RT
start individual tests. The tests require a real-time capable
Ö Simulation is characterized by deterministic execution,
remaining bus simulation, to enable reliable statements
short latency and quick response times.
about the communication behavior of the ECU under test.
Remaining bus simulation is executed exclusively on the
Real Time Rack Ö No disturbance of the simulation by the
The Solution PC’s operating system.
ECU tests within a remaining bus simulation on a FlexRay Real Time Rack is scalable Ö Flexibly adaptable to future
test bench test system requirements, e.g. number of FlexRay channels
Bertrandt created a special test system to conduct reproduc- or modification for other bus systems.
ible testing of FlexRay ECUs. It contains a simulated vehicle
environment that is implemented with an extensive and real-
time 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
10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 1

S P E C I A L E D I T I O N F L E X R AY l AUTOMOTIVE 2006 l1

FlexRay To d e t e c t e r ro rs i n t h e
d e s i g n o f a F l ex R ay s y s t e m

Sets the Pace 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.

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

To achieve the desired deterministic time behavior, one of Notification concept


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

2 l AUTOMOTIVE 2006 l SPECIAL EDITION 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 genera-
ted by the CANoe internal Realtime Workshop and a spe-
cial 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 CANoe’s strategy of transaction-
based updating of multiple TX requests, in which either all
Figure 1. Example of undersampling and oversampling or none of the send updates of a cycle are executed.
in an unsynchronized application
© automotive
Dedicated simulation environment
In simulating a model on hardware that is not real-time
capable and on a nondeterministic operating system, inter-
are missing. Any of the notifications may be limited to spe- ruptions and delays may occur in notification and execution
cific cycles (Cycle Multiplexing). The notification concept under certain circumstances. This results in large and non-
implicitly assumes that the actions occur at the time points deterministic jitter when accessing the communication
named above. medium. However such types of problems can generally
Send requests are normally executed at the next possible be minimized by deactivating certain system services and
send time after notification. If this send time is no longer applications that are not needed.
achievable due to faulty modeling or interruptions, the In projects with especially demanding real-time require-
system instructs the user by an alarm indication. This ena- ments, CANoe benefits from its dual-PC architecture (Figu-
bles detection of errors in the model or simulation platform re 4). This is realized by two sub-applications which run on
in very early modeling phases. different computers, so that real-time processing can be
separated from analysis and user control. The Soft Real-
Support of the model Time Client handles user interactions and the analysis sec-
To simplify specification of model behavior, first of all the tion, while the Real-Time Server is responsible for execu-
capability was created for symbolically accessing signal ting the models in real-time and interfacing to the bus
and message definitions in a FIBEX database; signals may systems and other I/O interfaces. The Real-Time Server
be interpreted and modified outside of the frame view. may run on Windows XP Embedded, and Windows CE will
Second, a buffer mechanism (Signal Layer) was imple- also be supported beginning in the first quarter of 2007. For
mented to enable reading and modification of signal values the most exacting real-time requirements Windows CE is
at any time. CANoe.FlexRay automatically receives and recommended together with special customized hard-
sends the associated FlexRay frames in background, whe- ware, e.g. VN3300 from Vector Informatik. This combina-
reby the send times are prescribed by the schedule in the tion is capable of task switching times less than 10 micro-
database. seconds 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
10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 3

S P E C I A L E D I T I O N F L E X R AY l AUTOMOTIVE 2006 l3
Summary
The presented real-time simulation system CANoe.Flex-
Ray 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 adap-
tation effort is necessary. Its special simulation mecha-
nisms and dual-PC architecture also make CANoe a con-
vincing solution in projects with higher real-time require-
ments. 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


Böke is Senior Software
Development Engineer
for the “Tools for
Networks and
Distributed Systems”
product line.

© Carl Hanser Verlag, München 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 opti-
mized run-time environment is that the Real-Time Server is
responsible for 100 % of the bus load of the FlexRay clu-
ster. 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 com-
munication cycle and handles in-cycle responses. Of cour-
se, in simulations with lower real-time requirements
CANoe can also deliver excellent results on single-PC con-
figurations under Windows 2000 or Windows XP.

Bus interfaces
For bus access the simulation systems need high-perfor-
mance interfaces that can be obtained from Vector. The
VN3300 is a FlexRay interface for the PCI bus that is espe-
cially 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
10 Press Book_Seite_1-46_1-49:Press Report 1 09.02.2010 13:12 Uhr Seite 4

1/49
11 Press Book_Seite_1-50_1-53:Press Report 4 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, wher-
ever access is needed to what is happen-
ing 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 re- FlexRay’s operation is not event-driven, but instead is time-trig-
quire inter faces for both stationary PCs and mobile notebooks (Fig- gered, it is necessary to synchronize all bus nodes. Send times are
ure 1). In both cases, they need to satisfy special requirements for precisely specified by the cyclic and synchronous time-division
simulation, analysis, calibration and testing. For example, an ECU’s multiplexing TDMA (Time Division Multiple Access) bus arbitration.
standard controller recognizes when errors occur, but does not pro-
vide any information whatsoever on their causes. For a qualified FlexRay Inter faces for all Requirements
analysis, the developer needs – besides the FlexRay messages and A new generation of FlexRay inter faces delivers the right solutions
signals themselves – precise time stamps, comprehensive informa- for all situations occurring in practice. In par ticular, one focus in
tion and detailed itemization of all states on the bus and in the in- their development was a high level of assurance of future utility.
ter faces. Compared to previous automotive bus systems, technical For example, updates to the FlexRay standard due to FPGA (Field
requirements for FlexRay are signif icantly more stringent. Since 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 con-
ceivable bus events due to their supplemental FPGA logic. They
record 100% of the bus traf fic of both FlexRay channels. The cen-
terpiece – 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


Overall, the inter faces were optimized for the best possible interac-
tion with the simulation and analysis tools CANoe and CANalyzer,
Figure 1: and the measurement and calibration tool CANape (Figure 2). The
Hardware inter faces must also be implementable in inter faces not only recognize all bus activities and buffer them as
mobile FlexRay applications. necessary; rather they also pass all information to the host. Dif fer-
ent than on controllers for ECUs, the controller host inter face is de-

1/50
11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 2

signed to record all data, null and erroneous frames as well as sym- achieve this. This per formance is enabled by the TX buffer that has
bols, including the associated timestamps and pass them on to the been extended to 2 MByte that can store over 1000 independent
software tools. This is the only way for developers to analyze, send messages. Previous solutions typically only had an 8 KByte TX
meaningfully interpret and thereby systematically troubleshoot buffer.
sources of errors. If no FlexRay synchronization is established or no
FIBEX database is available with TDMA parameters, an asynchro- The CANoe RT platform is especially well-suited to small to mid-size
nous bus analysis is possible, in which it is only possible to follow projects with real-time requirements, such as hardware-in-the-loop
events and log them in reading operation. In this mode, it is also simulations. It isolates visualization and control functions from the
possible to observe the star tup phase of a FlexRay network. The real-time simulation. The simulation is executed troublefree on a
measurement and calibration tool CANape gives developers the separate computer under Windows XP Embedded, and this guaran-
ability to access internal ECU parameters via the standardized tees reliable updates of send time points. The only inter face that
XCP-on-FlexRay protocol. In this case, the FlexRay hardware sup- comes into consideration for this computer, called a RT Box or RT
ports resynchronization of the FlexRay inter face if bus traf fic has Rack, is a fast PCI inter face such as the VN3300 (Figure 3).
been interrupted.
For minimal response times and deterministic timing behavior of
Maximum send Throughput for Simulations the application, short latency times and minimal jitters are
The requirements demanded by ECU simulations on the PC, e.g. with absolutely essential. Besides the time required for the actual com-
CANoe, are signif icantly greater than those for analysis mode. Sin- putations of the application, it is necessary to add the times for
ce multiple ECUs can be simulated simultaneously on a suf ficiently transport processes through the dif ferent communication layers.
fast computer, the inter face must also be able to handle the higher To achieve low PC loading despite this situation, DMA (Direct Memo-
data throughput while taking all timing requirements into account. ry Access) was implemented in the FlexRay hardware. DMA enables
Parallel simulation of ten or more ECUs is entirely realistic. It is high transmission rates and simultaneously relieves the main pro-
notewor thy that it only takes one of the new FlexRay inter faces to cessor and gives it more time for computations. Latency times were

Figure 2:
Hardware inter faces for
the entire FlexRay tool
chain: Analysis, simula-
tion, testing and soft-
ware modules as well as
physical generation of
bus disturbances.

1/51
11 Press Book_Seite_1-50_1-53:Press Report 4 09.02.2010 13:15 Uhr Seite 3

optimized – as was already done on CAN inter faces from Vector. The the multiplexing and demultiplexing of the PDUs into and out of
shortest latency times are system-dependent and can be attained the frames on the hardware side.
with PCI inter faces.
Hardware-based incrementing of a payload area serves to reliably
Intelligent auxiliary Functions for everyday Work of simulate a sender’s heartbeat. That is because, if it is not possible
Developers to guarantee this generation in a software-based simulation, the
Experience and customer requirements on numerous FlexRay pro- receiver might reject the signal or even switch itself off. The intelli-
jects motivated developers at Vector to integrate a number of other gent hardware prevents this by repeatedly sending the old signal
impor tant functions in the FlexRay inter faces: hardware support for values with counter incrementing, thereby reliably signaling that
PDUs, automatically incrementing message counters, simulation of the sending device is still “alive”.
inactive ECUs, group updates and autonomous bus start capability.
To decouple the transport layer from the applications, in the latest Simulation of inactive ECUs enables later deletion and supplement-
FlexRay networks PDUs (Protocol Data Units) have been introduced, ing of frames to be sent, even if the user has not yet defined them
instead of working directly with the relevant bus-specif ic data con- at star tup. The bus transceivers can be switched to inactive (Sleep
tainers. Several such logical PDUs may lie within a FlexRay frame. mode), after which wakeup patterns are still detected, however.
In this case, an additional piece of information is needed for each The bus transceivers can also actively execute a wakeup.
PDU, indicating whether or not the contents are valid for the cur-
rent cycle. One and the same PDU may also be defined in multiple If data that belong together do not fit in a FlexRay slot, there is a
frames. risk that it might not be possible to consistently transmit the data
The PDU concept enhances flexibility and enables easy reuse of the in two frames of the same cycle. This is remedied by a “group up-
application, but its disadvantage is that considerably more ef fort is date”, wherein the interrelated frames are always sent together.
required to generate and decode the FlexRay frames. Power ful To start up a FlexRay cluster, it is necessary to have at least two
FlexRay inter faces compensate for this disadvantage by handling

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 appli-
Figure 3: cations, analyses and simple simulations. The PCI var i-
Stringent requirements are satisfied by the real-time ant VN3300 supports complex simulations of multiple
capable and deter ministic CANoe RT runtime platform. ECUs with real-time requirements.

1/52
11 Press Book_Seite_1-50_1-53:Press Report 4 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-capa- In the area of FlexRay networking, Vector of fers a universal tool
ble; they always integrate themselves in the communication after a chain, modular software modules as well as inter face hardware and
successful external star tup. If a network line only has these kinds support for specif ic projects and a training program. The Stuttgart-
of devices for the measurement or simulation, the bus system can- based specialist’s activities as a Premium Associate Member of the
not be started up due to the lack of star tup-capable nodes. There- FlexRay Consor tium ensure that advanced developments and the
fore, a second communication controller or star tup controller has latest protocol specifications are always considered in the design of
been integrated in all FlexRay inter faces. tools and hardware inter faces.

Inter facing dedicated Applications with the Hardware


The new generation of FlexRay inter faces from Vector of fers high-
per formance hardware solutions for the most signif icant PC plat-
forms 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 Dr. Carsten Böke
simulations involving multiple ECUs under real-time constraints. studied Information Technology at the Uni-
versity of Paderborn. From 1995 to 2004, he
Currently, FlexRay buses are primarily used together with existing
was employed as a scientif ic assistant at the
CAN networks. The VN7600 FlexRay/CAN-USB inter face addresses Heinz Nixdorf Institute in the area of Parallel
this situation appropriately with two FlexRay channels and three Systems Design. While there he was primarily
CAN channels in one device. Developers of FlexRay/CAN applica- involved with automatic configuration of em-
bedded communication systems. Since 2004
tions benefit from simultaneous access to both bus systems in anal- he has been employed as a Senior Software
yses and simulations with just one hardware module. The combined Development Engineer at Vector Informatik
hardware solution for FlexRay and CAN especially simplifies precise GmbH, where he develops tools for bus anal-
ysis and bus simulation of FlexRay systems.
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 Alfred Kless
studied Electrical Engineer ing at the Techni-
solutions, since latencies must always be expected when USB is cal College of Esslingen. From 1991 to 2004,
used for inter facing. he worked in the area of Test System Devel-
opment at the company ALCATEL. Since
2004, he has held the position of Business
A programming library of basic functions is supplied with the Development Manager at Vector Informatik
FlexRay hardware. This makes it possible for dedicated applications where he is responsible for the product lines
to access the Vector FlexRay hardware. The “Advanced FlexRay Driver “Network Inter faces” and “Measurement and
Calibration”.
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 automat-
ic payload increment. Mar tin Goßner
studied Computer Engineer ing at the Techni-
Summary cal College of Ulm. Since 1998, he has been
employed in the “Network Inter faces” area at
FlexRay places dispropor tionately greater demands on hardware
Vector Informatik GmbH. Since 2000, he has
and software than CAN or LIN networks, for example, due to its been team leader for driver and firmware
time-triggered transmission method and considerably higher trans- development. As a product manager, he is
mission rates. Here, the timing behavior of the hardware has a deci- responsible for Vector FlexRay inter faces.

sive influence on the quality of software services that can be pro-


vided. Signif icant per formance increases are realized by transfer-
ring software functions to the hardware.

1/53
24 l AUTOMOTIVE 2008 l 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 PDU-
BASED 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 of tool development. Service Packs were delivered regular-

W 2.x database format, a new description sem-


antic was needed to define PDU communi-
cations between network nodes. To overcome this gap,
ly to Audi, thus, allowing early testing of ECUs with PDU
communication stacks. Audi delivered their latest FIBEX+
database versions to Vector in order to ensure CANoe’s con-
Audi successfully developed the FIBEX+ description tinuous compatibility. Close collaboration between Audi and
semantic. Vector was able to immediately support Vector accelerated the tool development and led to a pro-
FIBEX+ in its tools. Profiting from their experiences fessional analysis and development platform for FIBEX+ and
with FIBEX+, Audi introduced PDUs into the new FIBEX the new FIBEX 3.0 based FlexRay networks.
3.0 standard from ASAM (Association for Standardisa- This article illustrates the impact PDUs have on the inter-
tion of Automation and Measuring Systems [1]). nal structure and features of a FlexRay development tool
Continuous feedback from Audi enabled Vector engineers CANoe.FlexRay and how Audi engineers benefit from
to integrate important PDU features during the early phases appropriate tool support.
1/54

12 Press Book_Seite_1-54_1-57.indd 2 09.02.2010 13:23:50 Uhr


S P E C I A L E D I T I O N F L E X R AY l AUTOMOTIVE 2008 l 25
PDU Layer for Network
Analysis
PDUs are managed by tools for analysis,
simulation, and test as high-level com-
munication data containers (e.g. messa-
ges) containing signals. A FlexRay frame
can contain several PDUs. Since the lay-
out 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 loca-
ted between the bus and the user inter-
faces, 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 ena-
bled, then the complete symbolic databa-
se interpretation (PDU names, signals,
timings, etc.) of the network communica- Figure 1: CANoe’s Architecture with Abstraction Layers for Signal and PDU Hand-
tion is performed at PDU level. ling and Sending Behaviour (IL). © automotive
The PDU’s main property, which is defi-
ned by the Update Bit, is decoupled from
the frame’s occurrence on the network.
Thus, frames on the network may contain
updated and non-updated PDUs at the
same time. Update Bit values can be visu-
alized as pre-defined signals or can be
evaluated (e.g. in the graphics window,
see Figure 2). As a default for simple ana-
lysis or simulation received PDUs, which
have not been updated, are ignored. For a
detailed analysis, however, non-updated
PDUs can optionally be displayed and pas-
sed on to the simulated nodes. In addi-
tion, FlexRay frames including their pay-
load can be displayed and received as so-
called Raw Frames. Such PDU-based ana-
lysis features were heavily used by Audi
during their integration tests. Figure 2: CANoe’s visualization of PDU’s Update Bits in Graphics and Trace.
© automotive

PDU Layer for Network


Simulation
Although the FlexRay protocol defines frames to be trans- Message counters and check sums were defined by Audi
mitted cyclically (even without any update), native PDUs as additional but optional validity attributes of a PDU. In
do not have this property. If a PDU is not updated, the recei- fact, the Update Bits, message counters, and check sums
ver will normally not recognize the PDU. In order to trigger of a PDU are set independently from the application in
the receiver cyclically, PDUs must be updated periodically. CANoe by the Interaction Layer in order to simplify the
If the automatic transmission of PDUs with the Update Bit remaining bus simulation. Thus, the engineer can concen-
set (i.e. without any explicit data update) is required, then trate on setting appropriate signal values. A further use
the network designer can define these PDUs to have cyclic case is the insertion of explicit failures into the remaining
timings. For this reason an Interaction Layer (see Figure 3) bus simulation in order to test an ECU’s reaction. Therefo-
on top of the PDU Layer was developed to handle those re every automatic feature in CANoe can be disabled and
constraints. As an extension to the FlexRay protocol, PDUs the Interaction Layer can be used for fault injection.
may also be sent cyclically with (nearly) arbitrary periods A simulation of communications with an ECU depends on
with set Update Bit (without being updated). the occurrence of specific events (event-based simula-
1/55

12 Press Book_Seite_1-54_1-57.indd 3 09.02.2010 13:23:51 Uhr


26 l AUTOMOTIVE 2008 l 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 in CANoe’s Test Feature Set for PDUs. Additionally, for sti-
messages or changes in signal values from the bus. As mulus and response observations, PDUs can be sent inter-
such, notification handlers for PDU reception and signal actively (PDU Panel) by implicitly manipulating signals
changes are triggered by the PDU Layer. (Input Panels), higher level protocols (transport, diagno-
stics), or by a remaining bus simulation (CAPL, MATLAB
Performance Aspects models, etc.).
The additional (but mandatory) PDU Layer does create
some overhead. When receiving FlexRay frames, PDUs Conclusion
have to be extracted from the frame and then forwarded PDU-based communications will not only be used in migra-
to their notification handlers in the application. The same tion scenarios, e.g. when porting applications from CAN to
PDU can be contained in different frames. Thus, a sort of FlexRay networks, but also for new FlexRay develop-
de-multiplexing of PDUs from frames is implemented by ments. Audi has strongly influenced the development of
the PDU Layer. These procedures are highly optimized. FIBEX 3.0 based on lessons learned with FIBEX+. Vecto-
On transmitting PDUs, they must be stored in the appro- r’s experience with FIBEX+ allowed the quick support of
priate frame. The PDU can be located in different frames the new FIBEX 3.0 standard with CANoe. As communica-
according to the current (cycle) time or a different set of tions become more complex and extensive, appropriate
PDUs may be contained in the frame. This results in a high- modelling standards (i.e. FIBEX 3.0 and/or AUTOSAR), as
ly time-dependent multiplexed mapping of PDUs to Flex- well as their professional tool support, are essential requi-
Ray frames. If this is not fast enough, then frame slot mis- rements for an efficient FlexRay development.
ses should be expected. For maximum performance, Vec-
tor has implemented those functions to run on the hard- Literature:
ware for the FlexRay bus interfaces of the VN series. [1] www.asam.org

Testing PDU-based Networks


Audi and its Tier1 suppliers also benefited from CANoe’s Dipl.-Ing. (FH) Wolfgang Brandstätter
AUTOSAR features. This includes a check for communi- is Hardware and Protocol Engineer for
FlexRay;
cation conformance in order to test the AUTOSAR com- AUDI AG, 85045 Ingolstadt, Germany
munication stacks (especially the PDU Router) of the
ECUs. Here it is of great importance to be able to compa-
re 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. Dr. rer. nat. Carsten Böke is Senior Software
Tests can be split into two categories: First the applicatio- Development Engineer for the “Tools for Net-
works and Distributed Systems” product line;
n’s transmission behaviour can be checked with respect to Vector Informatik GmbH, 70499 Stuttgart,
updated PDUs and secondly, a signal’s integrity can be veri- Germany
fied according to the application. Audi‘s engineers have
successfully detected incorrect PDU update timings in
early development phases. These tests are fully supported

© Carl Hanser Verlag, München 2009. All rights including reprinting,


photographic reproduction and translation reserved by the publishers.
1/56

12 Press Book_Seite_1-54_1-57.indd 4 09.02.2010 13:23:51 Uhr


1/57

12 Press Book_Seite_1-54_1-57.indd 5 09.02.2010 13:23:52 Uhr


22 l AUTOMOTIVE 2009 l S P E C I A L E D I T I O N F L E X R AY

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 .

T
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 proto-
cols, 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 net-
work must therefore be simulated as communication
partners. This is referred to as a remaining bus simu-
lation. The strict time requirements associated with
FlexRay are very difficult to maintain; often simula-
tions on the FlexRay bus are non-deterministic in their
execution. The resulting slot misses result in over-
sampling or undersampling of data on the bus. There-
fore, it is often urgently recommended that these
simulations be executed on a dedicated, jitter-free and Figure 1: CANoe RT is used to simulate
deterministic (real-time capable) platform. Available or test ECUs in real time.
© automotive
solutions include expensive HiL systems and difficult

1/58

13 Press Book_Seite_1-58_1-61.indd 2 09.02.2010 13:24:05 Uhr


S P E C I A L E D I T I O N F L E X R AY l 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 simula-
tion 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 inte-
grated 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 communi-
simulation 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 interfa-
remaining 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 check- Testing by diagnostics
sums are already computed autonomously. This allows de- Access to an ECU’s diagnostic functionality is very impor-
velopers to focus fully on development or testing of the tant, especially in early phases of the development pro-
applications 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 CAN-
FlexRay gateway is needed for a FlexRay ECU. However,
Protocols on higher layers such a gateway is generally unavailable in early develop-
ECUs not only exchange signals such as vehicle speed and ment phases. That is why CANoe’s Diagnostic Feature Set
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 pro- direct access to the diagnostic data over the FlexRay bus
tocols, network management protocols, in flashing or cali- (figure 3). Special transport protocols for FlexRay (AUTO-
brating. During normal operation of the ECU, such proto- SAR, ISO and OEM-specific variants) are supported in this
cols are needed to coordinate bus communication. In ser- context.
vice phases, the protocols are used to evaluate or update After loading the diagnostic description databases in CAN-
the 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 OEM- available 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 infor- evaluate 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 dia-
A 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 integra- in 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 exten- A simpler way to create ECU tests
sions provide special dialogs for setting and querying para- Frequently 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 fre-

1/59

13 Press Book_Seite_1-58_1-61.indd 3 09.02.2010 13:24:06 Uhr


24 l AUTOMOTIVE 2009 l S P E C I A L E D I T I O N F L E X R AY

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 algorith-
mically. This makes it possible to execute loops or bran-
ching based on the results of prior tests. Static and algo-
rithmic tests may be combined.
Along with stimulation tests, the bus communication can
simultaneously be monitored regarding the FlexRay proto-
col. This includes detection of null frames and erroneous
frames as well as monitoring of the frame period, re-
sponse time behavior etc. Monitoring activities are per-
formed by so-called observational checks, which are alrea-
dy 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 Figure 3: CANoe.FlexRay directly accesses the ECU’s diagnostic
switch between connection of an original load or original functions over the FlexRay bus.
© automotive
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 systems require a powerful analyzing capability to test the
possible to simulate faulty behavior of a sensor or actuator internal communication between the SWCs. Therefore,
or a short circuit. the test tool needs access to the communication on the
VFB. This is usually done via XCP-on-FlexRay.
Testing AUTOSAR-functionality But especially extensive testing needs a higher perfor-
in FlexRay systems mance. Therefore, the coupling of the control unit with the
In the AUTOSAR design methodology, communication as test environment CANoe is done via a JTAG or Nexus
a basic service for the application is transparent. In the debug port. Only in this way parameters of the VFB, RTE
framework of the overall system, communication is de- or basic software (BSW) of a real AUTOSAR ECU can be
fined in the “AUTOSAR System Description”. If an AUTO- read-in and calibrated quickly. This will be done by connec-
SAR-ECU needs to be tested simply and quickly, the test ting the VFB of the real ECU to the test environment
tool has to know the communication description for the CANoe. Thus, the testing and analyzing at the ECU-internal
ECU. It is more user-friendly to directly read in the “AUTO- interfaces of the SWCs can be done quite similarly in futu-
SAR System Description” rather than the FIBEX databa- re, as today at the external control connections of an ECU.
ses. This will be supported by CANoe.FlexRay. If the requirements described are realized in a sophistica-
Key concepts in the AUTOSAR context are: “Software ted way in the development tools and in the implementa-
Components” (SWCs), “Runtime Environment” (RTE) and tion of FlexRay systems, FlexRay networks can be de-
“Virtual Functional Bus” (VFB). Even if the ECU does not veloped more efficiently than CAN networks.
physically exist yet, it must still be possible to test its “Soft-
ware Components”. For this purpose, the “DaVinci Com-
ponent Tester“ is able to integrate the real ECUs code of a Dr. rer. nat. Carsten Böke is Senior Software
SWC in the test environment. CANoe provides the RTE, Development Engineer for the Tools for Net-
VFB and basic software. The test is executed with the well- works and Distributed Systems product line
at Vector Informatik GmbH.
known functions of CANoe, including the automatic crea-
tion of a test report.

Outlook
In future, the number of AUTOSAR ECUs and the number
of included SWCs will grow rapidly. These complex @ Vector Informatik GmbH
www.vector.com

© Carl Hanser Verlag, München 2009. All rights including reprinting,


photographic reproduction and translation reserved by the publishers.

1/60

13 Press Book_Seite_1-58_1-61.indd 4 09.02.2010 13:24:06 Uhr


1/61

13 Press Book_Seite_1-58_1-61.indd 5 09.02.2010 13:24:07 Uhr


14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 1

Serial Bus Systems in the Automobile

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 info-
tainment 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 The already extensive wir ing cost and ef fort are increasing due to
and convenience functions in automotive technology. Experts pre- continual growth in networking of continually higher per formance
dict that in just a few years electronics will represent a share of up infotainment devices of dimensions that can hardly be managed
to 30 percent of vehicle value, and the worldwide market for elec- any longer. For tunately, some automotive OEMs recognized the ad-
tronics in cars will grow by approx. 6 percent annually to 230 billion vantages that bus networking would also of fer in this area early on.
euros by the year 2015. The automotive industry is forecast to ex- In the mid-1990s, BMW and Daimler began to develop a uniform
hibit rapid growth rates, above all in the infotainment area, given communication technology for serial transmission of audio and
the continually increasing vehicle-kilometers on Germany’s roads video signals in the vehicle based on the D2B bus (Digital Data Bus)
(according to DIW [1] approx. 700 billion). The average citizen developed by Matsushita and Philips.
spends about 270 hours in a car annually, whether it is on the way
to work, shopping or vacation. MOST Cooperation
In 1998, BMW, Daimler, Harman/Becker and SMSC (formerly OASIS
Over the course of time, the car radio was supplemented by the CD SiliconSystems) founded the MOST Cooperation [2]. Since that time,
and MP3 player. This came to include CD changers and navigation MOST has established itself as a de-facto standard for the transmis-
devices, and finally display screens also made their way into cars sion of multimedia data in the vehicle – the MOST Cooperation is
for replaying DVD and video films. Moreover, hands-free Bluetooth made up of 15 international automotive OEMs and more than 70 de-
units with integrated microphones and iPod control are gradually vice producers. The user organization laid the foundation for success
turning the cockpit a multimedia center, in which all of the play of the technology by defining an extensive specification. Version 2.5
lists and directories of a digital MP3 player can be displayed and of the MOST specification has been in existence since October 2006.
started directly on the in-vehicle display. 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
14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 2

The “Application” area describes a logical device model based pri- commands are used for control communication. Their core compo-
marily on object-oriented methods, with the purpose of transpar- nents are the FBlockID, FktID, Operation Type and up to 65535 useful
ent modeling and control of distributed infotainment systems. Fur - bytes.
thermore, it defines a hierarchical communication model as well as
services for managing an infotainment system. The “Network sec- System management
tion” describes the MOST Network Inter face Controller and its serv- The Application section defines higher-level function blocks and
ices, network management, and handling of data transport in a functions for system management. System functions include the
MOST system. The “Hardware section” deals with aspects of the “FktIDs” function (FktID=0x000) that is used to query the functions
hardware structure of a MOST device. supported by a function block, for example. The “Notification” sys-
tem function (FktID=0x001), on the other hand, enables creation of
Functional modeling the “notification matrix” for a function block. Emerging from the
A MOST device is subdivided into a functional level and a network “notification matrix” is information on which MOST device should
level (MOST Network Inter face). On the functional level, infotain- be notified if a cer tain proper ty of a function block has changed.
ment functionalities are embodied in so-called function blocks. This mechanism prevents an unnecessary increase in bus load in the
Each function block, e.g. the Audio Disk Player, provides the MOST MOST system.
network with a dedicated set of functions, e.g. “Track position”,
that can be accessed by operation types such as “Set” for setting a To query its function blocks and addresses, each MOST device has
track or “SetGet” for setting and reading a track (Figure 1). the “Net Block” (system) function block with FBlockID=0x01. The
function blocks can learn about the function blocks implemented
Functional addresses (FBlockID, FktID) are assigned to both the on a MOST device using the FBlockIDs function (FktID=0x000). The
function blocks and to the functions provided by a function block. FktIDs 0x002, 0x003 and 0x004 are used to find the physical ad-
They can be taken from the so-called “Function Catalog”, as can the dress, logical address and group address of a MOST device.
identifiers of the operation types. For example, the “Audio Disk The Network Master plays an impor tant role in the management of a
Player” FBlock has FBlockID=0x31 and the “Track Position” function MOST system. It is responsible for the system start and manage-
has FktID=0x202. ment of the “Central Registry”. This registry contains the logical
addresses of the MOST devices implemented in a MOST system and
The separation of function and network and functional modeling the addresses of function blocks contained in the MOST devices.
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.

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 over-
all functionality. On the middle hierarchical level are the usual con-
trollers. 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 en- Figure 2:
hances their flexibility with regard to configuration. It is easy to Hierarchy of a MOST system
add system slaves or remove them from a MOST system. MOST

1/63
14 Press Book_Seite_1-62_1-67:Press Report 3 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 com-
munication 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 hard-
ware (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 Figure 3:
MOST 25 to MOST 50 and MOST 150, this architecture has now en- Dif ference between NIC and INIC architectures in a
countered its limits. MOST device

In new developments, INIC (Intelligent Network Inter face Control-


ler) replaces NIC. While INIC assumes control of execution of time- communication partners (data source and sink) have connected to
critical por tions of the network driver of the EHC, just a relatively the same streaming channel, bit streaming begins (Figure 5).
small part of the network driver still runs on the EHC, which essen-
tially represents a socket for the application. The INIC architecture Connection or disconnection is usually made by a query by the func-
thereby relieves the load of the EHC. For control, the INIC provides tion block “Connection Master – CM” (FblockID=0x03). For this pur-
the EHC or MOST API (MOST Network Services) with a functional in- pose, the CM provides the two functions “BuildSyncConnection”
ter face, the so-called INIC-API. The functions of the INIC are encap- and “RemoveSyncConnection”.
sulated in a function block (FBlock INIC).
In the framework of building a connection, the CM requests that the
MOST Networking relevant data source, e.g. the TV tuner, have the suitable number of
MOST technology enables transmission of continuous bit streams streaming channels allocated by the Timing Master. That is because
(bit streaming) without buffer ing or unnecessary overhead. This in- the Timing Master is responsible for management of the “channel
volves having a specially designated MOST device (Timing Master) resource allocation table”. The CM passes the addresses of the allo-
feed the MOST frame (Figure 4) at a fixed frequency (44.1 KHz or 48 cated streaming channels to the data sink, e.g. to the display, so
KHz) into the transmission medium, which is typically optical. that it can connect to the streaming channels. Finally, the CM up-
dates the “sync connection table”, which it uses to manage all syn-
In a MOST25 system, the MOST frame provides 60 streaming chan- chronous connections. Disconnection is per formed according to the
nels at 8 bits (or 15 quadlets of 4 bytes each) for transmission of same scheme.
continuous bit streams (source data area). The bandwidth of a stre-
aming channel yields either 352.8 KBit/s (44.1 KHz) or 384 KBit/s To enable transmission of data packets, the user has the option of
(48 KHz). reducing the number of streaming channels by up to 24 (six quad-
lets) using the “Boundary Descriptor”. All those streaming chan-
Since the MOST devices are physically interconnected into a ring, nels that are not reserved for bit streaming, are combined to form
each MOST frame must pass through every MOST device at the fre- the packet channel. While a maximum transmission rate of up to
quency prescribed by the Timing Master. As soon as the relevant 12.7 MBit/s is possible at a frequency of 44.1 KHz, a maximum rate

1/64
14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 4

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

Figure 4:
Layout of the MOST frame: Sent in
administrative byte 0 are synchro-
nization infor mation and the
boundary descriptor, and in admin-
istrative 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 Finally, the MOST system must transmit the MOST commands need-
is managed by the Network Master function block (FBlockID=0x02). ed for management and control. Control messages (Figure 6) are
It can be set via the “Boundary” function (FktId=0xA03). used here, which are transmitted on the control channel (2 bytes).
Therefore, 16 MOST frames (MOST block) are required to transmit a
A Layer 2 protocol is used to transmit data packets. The frame com- control message. The bandwidth at 44.1 KHz is 705.6 KBit/s, and at
prises the arbitration field, source and target address, data length 48 KHz it is 768 KBit/s. Transmission of control messages is also
code, data field (either 48 or 1014 byte) and data protection. A based on a Layer 2 protocol. Bus access is implemented by the CSMA
token circulating in the ring regulates bus access. The MOST device method (Carrier Sense Multiple Access).
that takes the token from the ring may access the packet channel.

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 band-
width of 7.68 MBit/s for the trans-
mission of data packets.

1/65
14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 5

Figure 6:
Control message. A MOST block is
required to transmit a control mes-
sage. The control message is com-
posed of: arbitration (a), target
address (b), source address (c),
message type (d), data field (e),
data protection (f), acknowledg-
ment (g), and reser vation (h).

Physical Layer Development, testing and analysis of MOST systems


Today, optical conductors of polymer fibers (POF – polymer optical Vector Informatik GmbH has been an associate member of the MOST
fiber) are the state-of-the-art technology for transmitting audio Cooperation since 1999. Besides its extensive activities in the area
and video signals in the MOST system (Figure 7). Overall, the tech- of serial bus systems such as CAN, FlexRay and LIN, the Stuttgart-
nical proper ties of polymer fibers are far superior to those of elec- based networking specialist has been supporting the development
trical transmission media. Especially notewor thy are its excellent and analysis of infotainment solutions in the automobile since the
electromagnetic immunity and relatively high signal transmission year 2000. It of fers a comprehensive product lineup of analysis, de-
rate of up to 500 MBit/s. Fur thermore, the combination of POF, a velopment and test tools for applications such as high-end audio
red light-emitting diode as the light source (wavelength 650 nm) systems, multimedia streaming, telephone and navigation. Hard-
and a silicon PIN photodiode as the receiver represents a very eco- ware inter faces for bus access, a multibus data logger as well as
nomical and comparatively simple and manageable form of optical training courses and engineer ing and development services round
signal transmission. out its of fer ing [3]. The Vector Academy [4] supplies the necessary
basic knowledge related to ECU communication in the automobile
MOST 150, which follows MOST 50, is a MOST system that is current in the framework of seminars on CAN, LIN, FlexRay and MOST.
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 there-
fore handle the relatively short paths in the car of up to 20 meters
can without any problems.

1/66
14 Press Book_Seite_1-62_1-67:Press Report 3 09.02.2010 13:04 Uhr Seite 6

SE RI AL BUS SYS TEMS IN THE AU TO MO BILE

Background knowledge on signal transmission in a MOST system via POF

transition from the optically denser to the optically less


dense medium, the beam is refracted away from the prima-
ry axis. The angle of refraction a can be calculated if the
so-called indices of refraction n of the two media are kno-
wn (Snellius Law). If the light beam exceeds an incidence
angle a0 in the transition from the optically denser medi-
um to the optically less dense medium, then total reflec-
tion occurs.
This proper ty makes it possible to transport light in an op-
tical 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 re-
fractive 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
When a light beam passes from one transparent medium to anoth- so-called step-index PMMA fiber are obtained at 520 nm
er, it is refracted. The greater the angle of incidence, the greater (green), 560 nm (yellow) and 650 nm (red). Red LEDs are
the refraction. The medium in which the light beam forms a smaller generally used (attenuation 0.14 dB/m), since they are
angle with the primary axis is the optically denser medium. In the very inexpensive.

Figure 7:
Background knowledge on optical signal transmission in a MOST system

Literature and links:


[1] www.diw.de Eugen Mayer
[2] www.mostcooperation.com (Graduate engineer; technical teaching
[3] www.vector-group.net/most/en certificate); after vocational training as a
[4] www.vector-academy.com communication electronics technician, he
studied electrical engineering and technical
education at the Technical College of Ravens-
burg/Weingarten and the University of
Stuttgart. Since 1999 he has been employed
at Vector Informatik where he works as a
Senior Trainer.

1/67
15 Press Book_Seite_2-00_2-07:Press Report 3 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 develop-
ment process today, but there is unex-
ploited 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 Costs for tests represent a considerable share of a project budget,


Over the past ten years, the status of automotive electronics has but proper functionality of the ECU must be assured. Therefore, it is
changed fundamentally. At the beginning, just a few ECUs were impor tant to achieve a maximum of test quality and test depth with
used in the automobile but now more than 60 ECUs are being transparent concepts, e.g. by replacing insuf ficiently automated
installed in some luxury class cars. Additional electronic systems test steps by modern methods and tools.
offer improvements in the areas of safety, convenience and energy-
saving operation. Today, more innovations are based on electron- 2 Tool for analysis, simulation and testing
ics, and increasingly, a large share of this functionality is based up- The networking of ECUs represents the backbone of motor vehicle
on software. electronics. In this context, the method of remaining bus simula-
Growing complexity has made extensive and ef fective tests more tion provides an impor tant foundation in per forming ECU tests.
impor tant than ever before. The widespread use of numerous elec- Without at least a rudimentary simulation of the ECU environment,
tronic components has caused the number of potential error sour- most ECUs cannot be put into operation meaningfully. For example,
ces to rise dispropor tionately. Tests are indispensable in all phases many ECUs only operate properly if they serve network manage-
of ECU development to detect and correct errors early, keeping ment functions.
costs as low as possible. Some weaknesses of a total system do not CANoe from Vector Informatik is a widely used tool for analyzing,
manifest themselves until components are integrated under actual simulating and testing distributed, embedded systems (Figure 1).
and real-time conditions. This has turned testing into a cross- It is used widely for remaining bus simulation and supports all
departmental and cross-manufacturer discipline. impor tant bus systems – in par ticular CAN, LIN, MOST and FlexRay –
The enormous electronic problems that occurred in initial years for which Vector Informatik also supplies suitable PC inter faces.
have shown what happens when these facts are not considered and Commercially available inter face cards can be used to address the
systematic tests are neglected. The later that problems are identi- I/O lines of ECUs from CANoe. Moreover, Vector has announced
fied in the development process, the more serious impact there is an I/O hardware product that supplements these general capabili-
to the increase in cost. This becomes clear in an extreme way when ties with test-specif ic functions such as switching additional loads
correction of errors leads to costly recall actions after product has and short circuits directly to the ECU terminals.
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
15 Press Book_Seite_2-00_2-07:Press Report 3 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 data-
bases. 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 ca-
pabilities 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 environ-
ment for a component HIL tester.

Figure 2:
Dual-computer operation of CANoe Realtime of fers
improved real-time capabilities.

2/1
15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/2

3 Integration of testing and development Besides linking the dif ferent test phases, development and test ac-
Today’s development models call for tests in var ious phases of devel- tivities must also be interrelated and adapted to one another. Test-
opment (Figure 3). Generally, the individual tests are self-contained, ing must be understood as an integral component of development
separate activities that are per formed by specialized personnel at that requires comprehensive support using proper methods and
suitably equipped, dedicated workstations using special tools, lan- tools. This must be guaranteed in addition to the procedural and
guages and methods. In this context, test creation is of ten organized organizational integration. What is impor tant here is to make tests
as an independent task, detached from other development activities. available in conjunction with development, not just in the required
This segmented work approach results from distribution of the formal ver ification phases. Ideally, it is possible to per form tests
many dif ferent tasks of the development process to specialized directly at the ECU developer’s workstation with the resources ex-
working groups. However, if this separation of tasks is followed too isting there.
strictly, the numerous contact points between var ious development For this purpose, CANoe of fers a run-time environment for test
and testing tasks will most likely not be utilized optimally. For ex- execution that can be used in parallel to the remaining bus simula-
ample, only good coordination between component testing and tion and analysis functions. The process is very easy to set up, espe-
system testing can prevent expensive redundant development of cially if developers are already using CANoe for remaining bus simu-
test cases that are identical in content. When compatible tools are lation and analysis of bus communication.
used, test cases that have already been developed once can be used CANoe’s test component enables manual, semiautomatic, and fully
as a basis for other developments in var ious areas. This avoidance automatic execution of tests. The developer can begin with simple
of redundant developments frees up resources that could be used, tests and later expand and complete them. In general, the process
for example, to prof itably invest in the validation of existing test of creating complex tests is a task of validation departments that
cases and their advanced development. Comprehensive test man- build their tests upon the developer’s tests.
agement supplies a solid foundation for cooperation and, applying An impor tant foundation for such tests is the remaining bus simula-
the same resources, optimizes the depth and breadth of testing. tion, which ideally is not set up manually, but rather is automatical-
Coordination also helps to detect and fill gaps in testing. ly generated and parameter ized from the databases of the system

Figure 3: Tests are indispensable in all phases of development.

2/2
15 Press Book_Seite_2-00_2-07:Press Report 3 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 indispensable from the perspective of achieving quality-oriented,
DLLs (e.g. Interaction Layer, Network Management, etc.), which structured development processes.
are supplied with the tool or which Vector puts together as OEM- A test record is produced whenever a test is executed using CANoe,
specif ic modeling packets. The signals that the remaining bus sim- whether in the test laboratory or at a development workstation,
ulation supplies to the simulated nodes may be acquired directly and is created without inter vention by the user or test case devel-
from test scripts, or may be stimulated or added manually. oper. It is then available for tests accompanying development
In contrast to the systematically planned, executed and document- without requir ing additional ef fort. The XML format used for the
ed activities of the test phases, formal execution and documenta- test records is an open format thus other tools can be used for fur -
tion are generally omitted in tests accompanying development. ther processing of the results. For example, a test management
Never theless, these tests make substantial contributions toward system might be used to evaluate the test records in the context of
overall quality, because they give the developer the ability to deliv- a matur ity level analysis.
er a more stable product to the subsequent testing phase. 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
4 Matur ity level assessment and error analysis of unique identifiers (e.g. a requirement ID), which the test case
To assess the matur ity level of an ECU dur ing development, a developer references in individual test cases. CANoe automatically
comprehensive evaluation of all executed tests is necessary. The copies this identifier to the test record so that all test cases, test
quality of individual test results with regard to reliability and rele- results and requirements are clearly interrelated (Figure 4).
vance must be considered, but more impor tant is broad coverage At least as impor tant as recording and evaluating test results, is
of the required proper ties by suitable tests. Therefore, the results the analysis of the causes of the errors that actually occur. Most
of less formally executed tests are also helpful in matur ity analysis. test tools do not provide any such capabilities or provide just rudi-
A prerequisite for this – besides keeping records of test execution – mentary capabilities. One impor tant reason is that error analysis is
is the consistent use of configuration management. This is also 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
15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/4

First, they are faced with the problem of understanding errors de- Many ECU functions can only be tested meaningfully if deeper
tected in the test and tracing their causes. In par ticular, when er- access to the ECU is possible. Such accesses are provided by the dia-
rors are reported by test laboratories, the developer usually does gnostic and calibration inter faces, which are accessed via an ECU’s
not even have access to the systems used in testing. existing bus inter faces. It does not make sense to address these
Therefore, at the test bench it is mandatory to precisely record the inter faces by simple message sequences, since defined protocols
test procedure and log every interaction with the DUT, especially underlie the communication process. It is more convenient and
bus communication. Dur ing the role of analysis, CANoe enables reliable to have appropriate abstractions for diagnostics and cali-
replay and analysis of any desired recordings (log records). It is bration.
thus possible and beneficial to have the same type of test system at In CANoe, either description files from the CANdela tool or ODX de-
the development workstation as that of the test bench, so that the scription files are responsible for parameter izing the diagnostic ac-
developer can reproduce error producing test cases independently. cess layer. If no description is available for the actual diagnostic ca-
In many cases it is possible to execute the relevant test cases even pabilities of an ECU, a gener ic description for KWP2000 and for UDS
if many simplifications are necessary, e.g. to avoid addressing non- supplied with CANoe may be used. Either the gener ic description or
existent measurement hardware. a diagnostic description file customized for the ECU will of fer con-
venient access to the diagnostic services defined there. It is possi-
5 Signal abstraction and diagnostics ble to obtain the same abstractions and advantages as in the signal
Abstraction is a commonly used and impor tant method for handling abstraction described above.
complexity in software development and system design. This can al-
so 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 cor-
rect abstraction layer in composing tests not only af fects the ef fort
required to create test cases, and therefore costs, but also the qual-
ity of test cases. Like all other software components, the test cases
themselves may contain errors as well and should be checked be-
fore 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 func-
tionality, and this is why in the ECU the actual application is gener-
ally based on a signal abstraction (Figure 5). In a CAN system, for
example, an Interaction Layer in the ECU provides the signal ab-
straction. 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 en-
sures 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 sys- Figure 5:
tem’s communication matrix, it is usually possible to continue to Signals of fer an abstraction level between messages
use the test cases unmodified. With the same application, the ab- and I/O connections on the one hand, and between test
straction enables reuse of test cases in similar projects. def initions and simulation models on the other hand.
In testing ECUs, it is not only the signal inter face that is impor tant.

2/4
15 Press Book_Seite_2-00_2-07:Press Report 3 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 integrated in the patterns that are supplied (Figure 6). Test case
used to access internal ECU var iables via test scripts in CANoe. The generation is reduced to defining the target behavior, including
measurement and calibration tool CANape handles these protocols any supplemental data needed, such as the settling times to be tol-
and the ECU description files (A2L) that are needed. CANoe controls eranced.
CANape via the COM inter face. This accomplishes the same goals as To the extent that it is sensible, the supplied test patterns them-
in the signal and diagnostic abstraction described above. selves are placed on the signal abstraction described above and en-
able symbolic access to signals, messages, etc., via the associated
6 Ef ficient test generation databases. The use of diagnostic services or I/O signals is also pos-
A precise study of an ECU’s test cases will reveal that many of the sible. In short: The entire testing infrastructure of CANoe can be
test cases can be derived from just a few recurring patterns. This is used with test patterns. If there are requirements that extend
quite evident in gateway ECUs: A major ity of the test cases serve to beyond these capabilities, the option of programming the test
check the routing of signals and messages. Finally, the only reason cases still exists.
for the large number of test cases is the large number of possible Automatic generation of test cases is another method for creating
input and output data. But the same types of patterns are also tests ef ficiently, if suitable sources of information are available.
found in other types of ECUs. Expressed abstractly, this means that The contents of generated tests are by necessity limited to the de-
many functions are tested by first putting the ECU in a specif ic sta- scription levels and depths of the sources. Never theless, genera-
te using a suitable stimulus and then checking the state that is rea- tion of fers valuable support, primarily when it comes to cover ing
ched. The recurring pattern of these test cases is: Set signals (stim- the formally defined basic proper ties of an ECU by tests. The rela-
ulation), wait for the maximum allowable reaction time, and then tively low ef fort required to generate test results in quicker availa-
check the signals of the new ECU state. With some experience in bility thereby making it possible for earlier detection of undesirable
the use of test patterns, users will likely recognize a few additional trends.
run-time patterns from which many test cases can be derived. The tool chain from Vector utilizes such test generator approaches.
These patterns represent an oppor tunity for fur ther optimization of Description files such as the DBC database or CANdela def initions
test case generation. CANoe, in addition to of fer ing classic pro- are used as the source for the generator (Figure 7). The generator
gramming of test cases, also lets the user define test cases based uses them to generate test cases, which CANoe then executes. Sin-
on test patterns. It is no longer necessary to program the pattern ce test scripts may make use of the entire tool infrastructure, the
contents, since the procedures are already known and permanently 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
15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/6

Figure 7:
Test cases can be created from very dif ferent sources
using generators.

Thomas Riegraf (Graduate Engineer)


is Global Product Line Manager and
with just a little ef fort a generator can create suitable test cases responsible for the product line “Tools for
from a customer-specif ic gateway description (e.g. in the form of a Networks and Distributed Systems”
database or Excel spreadsheet). Thanks to the test patterns de- at Vector Informatik GmbH in Stuttgart.

scribed above, this just requires a simple transformation of the cus-


tomer-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 Siegfried Beeh (Graduate Engineer)


The only way for automotive OEMs and suppliers to deal with the is team leader and responsible for test tools,
diagnostics and modeling in CANoe
growing requirements for ECU tests is by ef ficient test creation and at Vector Informatik GmbH in Stuttgart.
automatic test execution. The testing tool presented of fers a prov-
en solution for implementing testing tasks with signal abstraction,
integration of diagnostic, calibration and I/O inter faces, the con-
cept of test patterns, and test case generators. CANoe is a high-
per formance runtime environment for testing ECUs and networks.
The tool enables early creation and execution of tests with little ef -
fort, right at the developer’s workstation. The open inter faces of Dipl.-Inform. Stefan Krauß (Graduate in
CANoe facilitate seamless integration in a comprehensive testing Informatics) works as product manager
strategy and tool-supported test management. Although some us- for test tools at Vector Informatik GmbH in
Stuttgart.
ers might still imagine it to be a futur istic vision, with suitable inte-
gration 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
15 Press Book_Seite_2-00_2-07:Press Report 3 09.02.2010 13:08 Uhr Seite 3/7

ECU Testing

Systemize your ECU test


XPSLçPXT
with systematic and reproducible tests. Efficient test systems
Distr. Systems
accelerate your CAN, LIN, MOST and FlexRay development.
Development

> Create real test environments during the early stages of


development using generated simulations of a remaining bus.
ECU

> Use automatically created test cases and test reports for
systematic component and system tests.
Diagnostics
> 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.
ystem re
Calibration

r VT S
ECU

a
> Test the full range of ECU functions with the VT System that Vecto hardw
r test m
can simulate or control the environment. o d u la s te
y s
The m m/vt-
Software
. ve c tor.co
www
ECU

Vector tools and services help you achieve optimum test


quality and test coverage within all development phases.
Management
Process

Information and Downloads:


www.vector.com/ecu-test

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. +49 7 11 / 8 06 70-0
www.vector.com
16 Press Book_Seite_2-08_2-13:Press Report 3 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 reli-
able 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 con- In order to validate the correct function of wiper motors controlled
trolled reversing DC motors to realize complex wiper movements by bus messages, Valeo needs to record and evaluate the physical
based on the OEM customer specifications. The wiper system has to parameters such as angle, revolutions, and current on the test
react flexibly and “intelligently” to environmental conditions. This bench. The determination and documentation of violations to cus-
can be realized with the use of a bus communication system. Addi- tomer specifications shall be rather simple and convenient. Valeo
tional features of reversing wiper motors are: engineers worked with dif ferent suppliers on var ious proposals for
> Software-based wiper field control the realization of such a test bench. Finally the concept of Vector
> Alternating park position to prevent permanent set of the rubber Informatik GmbH from Stuttgart, which is based on the flexible de-
element velopment and test software CANoe, was most convincing. A deci-
> Software control of wiper movement and other operating states sive factor for choosing Vector Informatik was Valeo’s experience in
> Service position for the exchange of wiper blades the successful application of Vector tools such as CANalyzer, CANoe,
> Load-dependent speed control and CANister.
> Overload protection 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 mo-
tor 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 technol-
ogy, 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 Figure 1:
profiles Wiper test bench at Valeo

2/8
16 Press Book_Seite_2-08_2-13:Press Report 3 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 cus- In order to achieve the required test coverage, the test bench is
tomer-specif ic test systems with CANoe. The Valeo test engineers equipped with five individual stations, permitting independent op-
and the Vector team worked jointly to determine requirements for eration. Each station is equipped with its own power supply, brake,
the configuration inter face of the test process control. Both project and bus inter face. The brake provides the load of the wiper motor
partners created the requirements for recording and evaluating with a maximum torque of 15 Nm. The test engineer specifies the
measurement data collectively. The development was initially based individual load in the test setup.
on a simulated test environment prior to testing and adjusting the
CANoe test system on the actual Valeo test bench (Figure 1). The bus communication between each test specimen and the CANoe
control is also provided separately in order to simulate the commu-
Customer-tailored hardware for recording measurement nication character istics between the electric motor and the ECU as
data realistically as possible. Vector created a remaining bus simulation
The test bench hardware was build by the Gesellschaft für Mess- for the CAN or LIN bus communication for activating the wiper mo-
und Systemtechnik (GMS) [Association for measur ing and system tor. Since there was not a real wiper ECU at the beginning of the
technology] in Spaichingen, Germany. DAQ cards from National In- project, the remaining bus simulation was expanded by an addi-
struments were used for recording analog and digital signals. The tional node that simulated the character istics of the wiper motor.
parameters such as angles, currents, voltages, and torques are re- After the integration of the real ECU, this node was simply deacti-
corded for each test station individually. Vector integrated the four vated.
data acquisition boards into the CANoe test system (Figure 2). For
standard applications this integration is realized using the CANoe The test bench is equipped with a standard industrial PC for the
port link feature. At that time (before version 6.0), CANoe did not simulation and control functions as well as for the evaluation of the
support the signal block transfer between data recording board and measured signals in parallel for all five test stations. The PC is also
CANoe. Thus Vector developed a CAPL-DLL customized for the appli- responsible for activating the wiper motors via the CAN or LIN bus-
cation, which expanded the CAPL programming language in CANoe es. A CANcardXL and two CANboardXL with the appropriate CANcabs
to include user-defined functions and inter faces. or LINcabs from Vector are used as inter face for the bus inter face.

This DLL is used to read and condition the measured signals directly Permanent set point/actual compar isons make the
from the input buffer of the hardware. This allows nearly real-time evaluation easier
signal processing with a high sampling rate. Then these signals are The test sequences of an endurance test are customer specif ic and
for warded to the data recording within CANoe (Figure 3). Parallel include all functions of the wiper motor. For example, an endurance
to the data processing via the DAQ boards, the test bench control test might last more than 1200 hours. The wiper motor is operated
activates the motors depending upon the test scenar ios using a at dif ferent loads and temperatures in all modes such as high and
low-speed CAN bus or a LIN-1.3/2.0 bus. low speed, inter val mode, off and sleep mode.

Figure 2: Figure 3:
Integration of CANoe in the wiper test bench Data evaluation in the CANoe node layer DLL

2/9
16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/10

Dur ing these tests, the monitored physical parameters such as cur- Synchronous recording of the bus communication with the physical
rent, rotation angle, the position of the motor output shaft, and measurement values already mentioned above is the critical factor
motor temperature are allowed to vary within specif ic limits only. in achieving the most useful test results. It has shown to be espe-
The limits are specified as envelope curves (Figure 4). In order to cially favorable that the recording of the bus communication, the
achieve the required accuracy for example of the RMS value of the measurement recording and the control of the test bench be done
current, the data is recorded with a sampling rate of up to 20 kHz. by a single software tool with a common time basis (CANoe).
Post processing of the raw data reduces the data to one single value
within 2 ms. CANoe is also responsible for compar ing the measured physical pa-
rameters and the bus communication with the specified limits. If
A part of the evaluation is the permanent compar ison between the critical events occur the results are recorded. I.e. if defined limits
measured signals and the specified envelope curve. The data is are exceeded or if switch-off criteria are reached. The latter is also
temporarily stored in a ring buffer. In case of deviations, CANoe used to switch off the test.
stores pre and post event data values (logging). The data volume is
adjustable (Figure 5). The Vector software application is able to The clear operating structure simplifies test configuration
record real time bus communication between the motor control and According to the specification of Valeo the Vector team also devel-
the wiper motor in parallel to the measured signals. If communica- oped a CANoe user inter face to create var ious test sequences, visu-
tion errors occur, the CANoe logging function records the measured alizations (Figure 6) and for the test bench control. The operator-
physical parameters as well as the corresponding bus communica- friendly user inter face allows the test engineers to create complex
tion, including the pre and post event data. 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 an-
gle. The CANoe application is able to distinguish dif ferent levels of
limit violations.

Figure 5:
Configuration of pre and post trigger times. In case of
Figure 4: an er ror, all events which occur in this time window are
Configuration of limit values stored.

2/10
16 Press Book_Seite_2-08_2-13:Press Report 3 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 from a true motor output shaft movement. The elimination of false
(Figure 4). If a high-level violation occurs the software interrupts data must occur rather fast due to the real-time signal compar ison
the test immediately. The dif ferent levels are adjustable in the setup. between the physical angel signals and the bus communication.

The application developers of Vector have prepared similar test pro- Dif ferent wiper test benches – one solution
cedures for the parameters current and temperature. The Valeo test After the successful implementation of the CANoe test application
engineer can pre-select how of ten the limit may be exceed before in the durability test bench for reversing wiper motors, both devel-
the software will terminate the test. In general, each tested wiper opment partners extend the application to test conventional rotary
motor can be started individually, i.e. it is possible to interrupt and wiper motors. While other test benches monitor the motor speed
continue a test individually. Parameters such as loading torque, and temperature only, this application improves the data acquisi-
voltage, or current can be adjusted separately. tion, real-time data monitor ing and data analysis.
Error logging stores the data in small blocks, which allows the test
engineers to per form analyses dur ing the test. The test bench soft- Valeo has already planned an additional expansion: the CANoe test
ware includes status logging which stores the current signals in fre- system should be enhanced to a mobile operating and data acquisi-
ely adjustable inter vals. tion system for bus controlled wiper motors for the use in conven-
tional test benches and even onboard test vehicles. This allows sim-
Compensation of environmental influences ple analysis of wiper systems in a wind tunnel or road testing.
Some boundary conditions made the development of measurement
and test algorithms very challenging. For example, the test bench With the planned extension of the application Valeo benefits from
is attached to a climate chamber for temperature testing. The com- the large data acquisition and analysis capability of the CANoe soft-
pressor of the chamber transmits vibrations to the test rig and the ware tool. The development team just needs to specify the options
tested wiper motor. The high-resolution angle sensor is able to re- that have to be implemented in the software. The expense is rela-
alize the vibrations as movements of the wiper motor even thought tively small: Valeo employees supported the Vector team with their
the motor output shaft is not moving. A damping or physical dis- specif ic product know-how and the def inition of the application.
connection of the compressor from the test bench would be ex- The “CANoe application team” from Vector started the development
tremely dif ficult, and an angle sensor with a lower resolution would of the test regimen, bus communication and the data acquisition as
not fulfill the required measurement accuracy. well as the evaluation of the test data with two engineers. Subse-
quent expansions has been realized with one person form both
In order to compensate such errors, the measured data are post partners.
processed using digital filter ing and compared with specified speed
limits. In case the software detects a continuously oscillating move-
ment within cer tain limits, it is able to dif ferentiate these signals

Figure 6:
Configuration of test procedures

2/11
16 Press Book_Seite_2-08_2-13:Press Report 3 09.02.2010 13:13 Uhr Seite 3/12

Valeo and Vector clearly exceeded the objectives set for this project Dipl.-Ing. (FH) Dietmar Baumgärtner
by reacting flexibly to unforeseeable challenges along the develop- studied precision mechanics at FH Heilbronn.
ment and implementation process. Fur thermore they are planning He is manager of system and component
testing for wiper systems at Valeo Wischer-
an extension of the application as more capabilities of the CANoe
systeme GmbH in Bietigheim.
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 develop-
Dipl.-Ing. (BA) Benjamin Dietz
ment to the validation, thus guarantying its customers the delivery studied Mechatronics at BA Stuttgart and
of reliable products. 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 test-
ing equipment.

Dipl.-Ing. Katja Hahmann


studied electrical engineer ing at TU Chem-
nitz. 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 Brändle


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
16 Press Book_Seite_2-08_2-13:Press Report 3 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 Test Execution Time Dramatically Reduced
its business, focusing on the development and manufactur- Automating ECU test execution, pass/fail detection and re-
ing in-vehicle instrumentation. Nippon Seiki’s technologi- port generation helped Nippon Seiki to successfully reduce
cal competence in this field is highly rated, and as a leading total ECU test time from more than 18 hours to just over 12
manufacturer of instrument panels it supplies a large num- hours. In particular, test execution time, which previously
ber of automobile and motorcycle manufacturers. took 11 hours, has now been shortened to about 4 minutes!
The more frequently testing is executed, the greater the gains
The Challenge in testing efficiency. Finally, use of the CANoe Test Feature
Set has dramatically reduced the man-hours needed to per-
Reducing ECU testing man-hours while simultaneously im-
form the tests (see table below).
proving quality of overall testing
A System Design Department Manager described the advan-
With growing computerization in automobiles, instrument
tages of automatic execution like this: “There is certainly
panels are moving toward multifunctionality. That is why
some test case implementation work to be done when auto-
manual ECU test execution, pass/fail detection, and creating
mating. But once the test case is created, the ability to reuse
reports took a huge amount of time. This has resulted in in-
it again and again is a huge advantage. In turn, this improves
creased ECU testing man-hours, and their reduction has be-
overall testing quality.”
come a major issue.
In this project, 30% of all ECU test cases are automated using
the CANoe Test Feature Set. Nippon Seiki will be expanding its
The Solution automated testing coverage in the future and targeting even
Automation of ECU Testing using the CANoe Test Feature Set greater efficiency in ECU testing.
CANoe, provided by Vector, is used by a large number of cus-
tomers 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, includ-
ing 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 conven-
tional 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 ECU’s 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 indus-
try. 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 reactions. Additional devices are necessary to cover fault states;
in the automobile. Therefore, verification of development results they are placed in the circuit between the ECU’s ports and the origi-
not only covers the mechanical systems, but to a large extent the nal or simulated sensors and actuators (Figure 2). Such test
electronic ECUs and their software as well. The complexity of heavi-
ly 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 tri-
als, 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 Figure 1:
important is broad coverage of potential fault cases. In testing Different test methods are used in the various
normal operating functions it is usually sufficient to connect the development phases.
ECUs to their original components, operate them and observe their

2/14

17 Press Book_Seite_2-14_2-19.indd 2 09.02.2010 13:24:23 Uhr


XXXXXXXX

components are often referred to as fault simulators. They might system may make fault memory entries, deactivate certain func-
be used to disconnect lines to simulate line breaks, for example. tions in the ECU or generate error messages. So the sensors and
In testing an individual ECU, besides controlling the hardware’s actuators are even needed for tests in which the functionality of a
input and output interfaces, the communication interfaces of the sensor or actuator is not really of importance.
DUT also play an important role. This places high requirements on A commonly used solution is to connect original sensors and
the test software, since – besides providing pure bus access for actuators directly to the ECU. Many developer test benches are
CAN, LIN, FlexRay or MOST – it must be possible to comprehensively equipped with simple connection boxes for this purpose, which
and reliably operate the ECU’s software or protocol interfaces, e.g. take the necessary components and have suitable cable connec-
diagnostics via UDS or calibration via CCP/XCP. So the layout of tions. Similarly, original sensors and actuators are also provided to
hardware and software interfaces has an enormous effect on the the ECUs under test on large test benches. However, automating
performance, flexibility and, last but not least, the costs of a com- the test processes is often problematic, since original components
plete test system. must be operated, e.g. by actuating robotics.
An alternative to connecting original sensors and actuators is to
Challenge of functional testing use substitute components. For example, a suitable resistor may
serve as a practical substitute for a lamp. Since the ECUs are only
In verification of ECU functionality, the primary task is to represent equipped with simple measurement circuits to monitor their con-
the ECU in an environment that mimics the real vehicle environ- nected components, generally a simple sensor or actuator simula-
ment as closely as possible. The sensors connected to the ECU are tion is sufficient. Compared to the use of original components, this
operated to activate the functions to be tested, and the ECU’s reac- enables compact and simple test systems. Similarly, it is relative
tions are evaluated. There are very different ways to produce a suit- easy to automate user inputs with suitable test setups, e.g. by
able ECU environment. What is important is that the ECU must not using relays or switches.
be able to perceive any differences between the real environment In so-called Hardware-in-the-Loop systems (HIL) the overall
and the environment simulated by the test system. In the end, the environment is modeled – including physical and dynamic process-
extent of efforts primarily depends on test objectives. es in the connected components. In this case, however, simulation
In the simplest case, an elaborate stimulation circuit is omitted and test execution would require elaborate and cost-intensive test
and the ECU’s inputs are operated directly by simple means, e.g. by systems, and they would not always be available where they are
manual switches between specific ECU lines. The ECU’s outputs needed. This also applies to the necessary knowledge of operators.
remain unconnected for the most part. Testing the ECU’s reaction
might only involve measuring the voltage at an output, for exam- Simulation of fault situations
ple. Such approaches usually do not lend themselves to automatic
test execution, but they are easy to perform – especially during To test an ECU’s reactions to faults in the connected environment,
development. the test system must be able to produce various fault situations.
Increasingly, many of today’s ECUs can no longer be operated in Extensive tests under these atypical conditions are especially
this way. Since they automatically check the sensors and actuators important, because they occur very seldom in driving trials or on
in many cases, it is essential to connect them during the test. If an the test bench and are difficult to reproduce. In the development
external component is faulty or is not even present, the associated of hardware and software, many fault situations are frequently

+ +

In ECU Out
Sensor Actuator
under Test

controlling, fault CAN, LIN, fault observing


stimulating injection FlexRay... injection reaction

Figure 2:
Fault simulators are inserted
Automated Testsystem between the sensors/actuators and
the ECU.

2/15

17 Press Book_Seite_2-14_2-19.indd 3 09.02.2010 13:24:24 Uhr


forgotten, because the primary focus of developers is on the > Sensors or actuators are damaged: sensors do not supply any
desired functions. To achieve reliability of systems, however, it is values, values lie outside allowable value range, or a compo-
critically important that the ECUs also react properly in response to nent’s electrical properties, e.g. internal resistance or current
faults. draw, do not conform to the specification.
In conjunction with sensor and actuator connections, it is espe- > Incorrect input values, especially incorrect sensor data: from the
cially important to simulate the following fault situations: perspective of the ECU, the sensor is operating properly and
> The electrical wiring is damaged: open circuits, short circuits to measured values also lie within the allowable ranges. Yet, the
ground or battery voltage, short circuits between certain values are implausible or contradict other sensor values, and the
connected lines. ECU must recognize this.

In all cases, the ECU must continue to work in a defined way. Fur-
thermore, 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 ECU’s software interfaces – typi-
cally 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
Figure 3: interface to CAN, LIN, FlexRay or MOST. Measurement and test
The VT System consists of standard 19-inch housings hardware is controlled or driven via GPIB or the serial port, and
with their own backplane into which the modules are integration of standard I/O cards from various manufacturers
inserted. This lets users implement individual and enables setup of test benches with a wide variety of complexity.
flexible test solutions depending on requirements. In driving the ECU I/O lines during an ECU test, Vector offers a
compact solution with the VT System (Figure 3). The ECU’s I/O

Actors

VT System

ECU
+ -
under CANoe
Power Supply Test Vector
CAN, LIN, Businterface
FlexRay, ...

Figure 4:
The VT System is placed in the I/O
Sensors
lines between the ECU and actua-
tors or sensors.

2/16

17 Press Book_Seite_2-14_2-19.indd 4 09.02.2010 13:24:24 Uhr


COMPREHENSIVE ECU TESTS WITH FAULT SIMULATION
XXXXXXXX

lines – and if necessary original sensors and actuators – are con- be operated simultaneously. This enables simulation of multiple
nected to the modular system (Figure 4). The PC is connected to faults and more complex operating processes.
CANoe via a fast Ethernet-based real-time network. This makes it Additional relays are used to represent faults such as line breaks
possible to assemble flexible test systems without great integra- and short circuits. In operation, such faults typically occur due to
tion or wiring effort. The VT System is well-suited to both small test damaged wiring and problems at the plug connectors. Even when
setups at a developers’ desk as well as comprehensive test benches there are just a few connection lines on an ECU, the enormous num-
in the test laboratory. ber of resulting combinations can hardly be fully tested. However,
The VT System simplifies the process of setting up test benches with their knowledge of physical conditions existing at the ECU,
immensely, since it integrates all components needed for an I/O persons creating test cases can limit the selection of test cases to
channel’s switching circuit in one module (Figure 5). Examples of isolated faults and the most likely combinations. For example,
such I/O channels might include an ECU’s output for driving a short circuits only occur at adjacent pins on the connector. In the
headlight or an input to be connected to a temperature sensor. VT System, the necessary switching options are once again avail-
Since two-wire connections are made for all channels, the system able for every connected ECU pin, so that test case selection is
supports all input and output types relevant to practice, e.g. driv- unlimited, and multiple faults can be covered.
ing motors via an H-bridge in the ECU. It is somewhat more difficult to simulate sensor and actuator
The measurement and stimulation devices contained in the mod- damage. In this case, it is not possible to revert to the original
ules are – like all components – designed for voltage ranges up to components, since the effort required to prepare them is extremely
32 Volt that are typically used in the automotive industry. They high. That is why simulated components are used when working on
require units for signal conditioning, which are already integrated the test bench. The simulation does not need to be “perfect”. In
in the module. The modules can also handle the high currents that general, it is sufficient if the properties of sensors and actuators
may occur when lamps and motors are driven. Relays on the mod- are simulated, and if they are detected and evaluated by the ECU.
ules serve to connect the ECU lines to the attached original sensors In the VT System, an electronic load is available for every ECU out-
and actuators. put for use in an actuator simulation or load simulation. In simulat-
It is relatively easy to set incorrect sensor data with original sen- ing faulty sensors, the sensor simulations described above are
sors, since here the sensors just need to be operated to be implau- implemented as a resistor decade or output voltage. If there are
sible. However, the number of conceivable value combinations is not enough integrated components for a test, it is possible to con-
large. For systematic testing, a high level of automation is there- nect external load simulations, sensor simulations or measurement
fore desirable; to make it possible to reproduce as many fault pat- and test instruments via bus bars.
terns as possible within a short period of time. Therefore, one Test case creation accounts for a significant share of overall test
approach is to replace the original sensors by electronic simula- costs. Therefore, for efficient work processes the developer not
tions. They are present on the VT modules for each channel and can only needs the right hardware support, but also an optimal inter-
be controlled in any desired way by CANoe as a test system. face to the test automation tool. In CANoe, after a simple configu-
The sensors are simulated by a resistor decade or a voltage out- ration of the VT System, all relevant data is available as system
put with relevant signal conditioning. There are stimulation units variables. The user selects them via a graphic user interface in the
for each of the VT System’s I/O channels, so that all ECU inputs can Test Automation Editor and applies them in the test sequences

Figure 5:
All components
needed to test an
ECU’s I/O channel
are contained in
the VT modules.

2/17

17 Press Book_Seite_2-14_2-19.indd 5 09.02.2010 13:24:24 Uhr


(Figure 6). This means that the input and output signals, as well as Literature and links:
most control signals, can be addressed as easily as the bus signals [1] Riegraf; T., Beeh, S.; Krauß, S.: Effizientes Testen in der Automobilelek-
of the communication interfaces. The VT System is thereby seam- tronik [“Efficient Testing in Automotive Electronics”]. ATZ (Volume
108), Issue 7-8, 2007, pages 648-655
lessly integrated in the CANoe test environment.
[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 ECU’s sensor inputs and evaluating the reac-
tions 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.
Dr. Stefan Krauß
The VT System from Vector gives the test engineer a compact and studied Computer Science at the University
at the same time powerful solution for connecting an ECU’s I/O of Stuttgart from 1990 to 1995. After earning
channels to a test system with CANoe. The modular system provides his degree he worked on the technical staff
of the university’s Institute for Computer
– for each channel – all key components for load and sensor switch- Science in the Software Engineering depart-
ing as well as their simulation. It also offers the equipment needed ment until 2001. Since 2002 he has been
to create the different fault situations. These functions and proper- employed at Vector Informatik GmbH in
Stuttgart, and is currently Product Manager
ties of the VT System make it easy to set up test systems – together
for the VT System.
with CANoe – that can be used flexibly for ECUs in the automotive
field.

Figure 6:
The VT System’s
measurement and
output signals are
directly accessible
in CANoe – on the
right side of the
Test Automation
Editor here.

2/18

17 Press Book_Seite_2-14_2-19.indd 6 09.02.2010 13:24:25 Uhr


2/19

17 Press Book_Seite_2-14_2-19.indd 7 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 soft-
ware testing of electrical power steering units by using the methods of limit value and effects analysis to reduce the num-
ber 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 cost- for the driver according to the situation. The system (Figure 1)
intensive tests and simulations are necessary, especially when soft- only operates and only consumes energy when the driver turns the
ware 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 Figure 1:
documented by appropriate safety verifications. Testing the Electrical Power Steering (EPS) system for
The advantages of electrical power steering (EPS) – compared to power assist when needed is extremely complex due to
conventional hydraulic power steering systems powered by the the large number of input parameters.
vehicle’s engine – are related to its ability to provide power assist

2/20

18 Press Book_Seite_2-20_2-23.indd 2 09.02.2010 13:27:20 Uhr


steering wheel. An EPS offers better control and contributes to several years to test. Practical testing would therefore require that
improved fuel economy and reduced emissions. For the driver, it is the sum of all possible input combinations be reduced to just a few
important for the EPS to exhibit continuity in its capabilities and representative test cases while achieving high test coverage.
driving dynamics. Whenever updates are made to new software This can be achieved by combining and applying several test
revisions, there is always the risk that undesirable side effects methods, such as the equivalency class method, limit analysis and
might be introduced along with the desired changes. In most cases, the pairwise method. Daimler uses the HIL test bench in effects
they just irritate the driver; in other cases, unlikely input signals analysis to find those signals that have the greatest impact on sys-
might cause serious malfunctions, including complete failure of the tem behavior. In addition to the three test methods mentioned,
EPS, that would impair driving safety. Thus whenever the software optimization by knowledge integration, i.e. focusing on frequently
is changed, reevaluating it is essential by running regression tests occurring input combinations in the application, is indispensable.
to reveal changes in steering behavior between different software Knowledge integration (Figure 2) produces meaningful test cases
levels. and makes a valuable contribution toward increasing software
quality. After the reduction process, 704 relevant test cases
Embedded software requires black box tests remained, requiring approx. 12 hours of testing.

Since EPS is a supplied system, Daimler does not have access to any Real-world data instead of high-cost HIL
detailed information on the embedded software – except for a few
parameters and characteristic curves. All tests and evaluations must In practical tests on the HIL test bench, semi-simulated driving
therefore be executed as black box tests. Another problem is the maneuvers (replaying and calibrating recorded real driving maneu-
large number of input parameters: There is not enough manpower or vers) play a key role. The tests are based on a catalog of standard
time to run through all theoretically possible combinations in HIL driving maneuvers that define the desired EPS behavior in specific
(Hardware in the Loop) simulations or even real driving maneuvers. situations. These include actions such as slalom driving, ISO lane
That is because, besides manual steering torque as a basic input change, circular driving, braking in a curve, steering wheel pull,
variable, there are 47 other signals that significantly influence the Elk test, etc. Vehicle developers drive these standard maneuvers in
system. The sheer number of possible combinations of input param- real vehicle tests. This involves logging the bus traffic in the vehi-
eters yields an incredible number of test cases that would take cle by laptop with CANoe, the test and simulation tool from Vector

Figure 2:
Reducing the
number of test
cases by know-
ledge integration

2/21

18 Press Book_Seite_2-20_2-23.indd 3 09.02.2010 13:27:21 Uhr


(Figure 3). This “real world data” can then be replayed 1:1 on a system developed by Daimler, the logged measurement data are
test bench to recreate the EPS as a virtual environment. sent to a Replay block in CANoe for playback (Figure 4). In the first
However, it does not make sense to just test the original driving branch, a blocking filter removes the CAN messages sent by the EPS
maneuver; instead the EPS is tested in modified scenarios of the in the vehicle to avoid overlapping signals. In the second branch,
tests cited above as well as in limit conditions, e.g. at higher vehi- the system generates the calibrated signals and computes the ana-
cle speeds, different engine speeds, friction values or modified log voltages. This is done with the help of the script language CAPL
manual steering torques. To do this, it is necessary to set and integrated in CANoe, which is based on a simplified C-language
adjust certain parameters during the simulations. In the test 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

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, sec-
ond, 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 ana-
lyzed offline with Matlab/Simulink. To do this, CANoe exports the
target and actual values in .mat format. So far, no online evalua-
tion has been necessary, but it would be possible by integrating the
Figure 3: Matlab/Simulink models directly in CANoe. The EPS is considered
Test setup for logging real bus communication, driving functionally capable if deviations of the actual EPS torques from
the HIL and evaluating measured values. 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

18 Press Book_Seite_2-20_2-23.indd 4 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 and those that are smaller, with each performing a test in that
have now been reduced to a minimum. range. The equivalence class method is prescribed by IEC
61508/ISO 26262.
Summary
Limit Analysis
The testing approach for evaluating software levels and revisions This is based on the equivalence classes, where the primary
described here met Daimler’s expectations for the project. Suitable focus is on the limits or extremes of the value ranges, e.g.
test methods combined with intelligent knowledge integration reduce maximum defined signal values, steering torques, etc. Experi-
the theoretically possible number of test cases to just a few conceiv- ence has shown that the causes of errors can often be found
able combinations of input signals. Daimler engineers were able to there. Besides limits, it also makes sense to test values 1
obtain conclusive test results on the behavior of the EPS as a black greater and 1 smaller to discover overruns, interpolation
box with relatively little time and effort. Instead of computing driving errors, etc.
situations and effects analysis with a complex, exact vehicle model in
cost-intensive HIL systems, logged real-world data is used, which can Pairwise Method
be modified in semi-simulated driving maneuvers. The simulation and This is the accepted and widely used practice for testing all
test system CANoe provides valuable services here; it runs on a lap- combinations of two signals. However, since blind application
top, so it is ideal for logging standard driving maneuvers in the real of this method almost always leads to unlikely test combina-
vehicle and conducting tests. During these semi-simulated driving tions, it makes sense to select combinations with knowledge
maneuvers, the Vector system is responsible for key system functions integration, to focus on typical input combinations of the
ranging from replaying, filtering and modifying the real world data in application in question.
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 posi-
tive experience the department has had with the system. The test Andreas Herp (Graduate Engineer),
platform, together with the HIL computer, is so compact that Daimler studied electrical engineering at the Univer-
can take the entire system on real test drives at any time. sity 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 develop-
ment of electrical power steering, and he
directed the thesis work by Mr. Herbert.

Michael Herbert (Graduate Engineer),


studied electrical engineering and informa-
tion technology at the Technical University of
Darmstadt. As part of his undergraduate
thesis work at Daimler AG, he researched
Figure 5: the topic of Effects and Limit Value Analysis
Real measured target values are compared to HIL of an EPS. Since October 2008, he has been
working at Daimler AG as a computational
output values in Matlab.
engineer for handling simulations on the
S-Class.

Equivalence Class Method Oliver Falkner (Graduate Engineer),


Equivalence classes are made up of input or output values pre- studied electrical engineering at the Univer-
sumed to elicit an identical system reaction, i.e. instead of sity of Stuttgart. After graduating, he joined
Vector Informatik GmbH in Stuttgart in 1999,
testing all of them, only one or just a few representatives of
where he is currently senior product manage-
the equivalence class are tested. All valid values of a defined ment engineer in product management of
input range might define one equivalence class, for example, the Networks and Distributed Systems prod-
when values outside of the defined value range represent uct line.

another equivalence class. The latter class can itself be subdi-


vided into values that are larger than the valid value range

2/23

18 Press Book_Seite_2-20_2-23.indd 5 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 com-
mercially available since 2007. The automatically generated test cases simplify regression tests during iterative develop-
ment of complex models. Transformations make it possible to re-use the test cases that are generated, e.g. in ECU accep-
tance 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 requirements. The test specification should be used again to verify
great innovative potential. Great software complexity and the over- the functional model. This process reveals errors and inconsisten-
abundance of resulting information raise the quality assurance cies in early development phases, which can then be corrected at a
issue of how to effectively guarantee consistency of the model and fraction of the cost of correcting them later, after system or accep-
code. Test strategies and processes used during the early stages of tance testing. Broad tool support also promises minimal time to
development will reveal technical and design errors early, when develop the ECU software, e.g. by using automatically generated
they can be corrected much more cost-effectively. production code (Figure 1).
Model-based development is a software engineering method Stepwise development and verification of complex functional
which – in addition to documenting the system – also utilizes auto- models assumes efficient test methods. A check must be made at
matic generation to produce a large share of the test documenta- each step in the development process to verify that no errors have
tion. In practice, most test cases are still created manually. In a been introduced. In a process known as model-based testing, test
classic document-based approach, test cases are derived from case generators take functional models and automatically generate
requirements and described in a test specification. From this speci- test cases, which can then be automatically executed, evaluated
fication, tests are implemented to verify proper software imple- and documented.
mentation in the ECU (Figure 1). Other issues involve where it makes sense to apply automatically
Over the past five years, automotive OEMs have been applying generated test cases and which advantages they offer in the devel-
more and more model-based methods to develop embedded soft- opment of embedded vehicle systems. The new approach can be
ware. One possible approach that integrates these model-based used during iterative development of functional models to auto-
methods into the development process is one in which the software matically generate test cases for regression tests, for example.
is manually implemented in the ECU while functional models are Another possibility is to re-use the test cases generated from this
created in parallel (Figure 1). The development of executable func- development phase in later testing phases of the development pro-
tional models represents a quality improvement in requirements cess, such as in ECU acceptance tests (Figure 1).
analysis and development. First, the functional models define func-
tions and then validate them with respect to the given

Figure 1:
Comparison of
different
approaches to
developing ECU
software

2/24

19 Press Book_Seite_2-24_2-27.indd 2 09.02.2010 13:27:06 Uhr


Test case generators simplify regression tests coverage entails immense effort, because if there are coverage
gaps, the related code sections must be analyzed, and other
Requirement definitions are often subject to change. Any errors requirement-based test cases may need to be manually created
discovered in the requirement definitions are corrected, and new until the necessary code coverage is attained. Because of this
functions may be added to extend the functionality of the system immense effort, it is no longer advisable to manually create test
being developed. Later in the development process, the implemen- cases for the regression test.
tation is often restructured or simplified – all while retaining its One answer lies in the use of new commercially available test
functionality, of course. Functional models that have already been case generators, such as Simulink Design Verifier from The Math-
developed are then adapted to the new conditions. During this pro- works or Telelogic Rhapsody ATG from IBM. Test cases are automati-
cess, the developer must ensure that changing a functional model cally generated after specifying a specific code coverage to be
does not introduce any new errors or undesirable effects on func- attained. The test cases then increase the quality of the compari-
tionality. This can be accomplished by using regression tests [1]. son. In addition, the tools can often simultaneously generate an
Three steps are necessary to attain this goal: MiL test environment, execute test cases and automatically gener-
> A suitable Model-in-the-Loop (MiL) test environment must be ate a test report. This results in a working method that can be used
developed for the regression tests throughout the system which has quite short throughput times.
> Test cases must then be automatically executed in this MiL test This in turn further simplifies the execution of regression tests for
environment functional models, which results in cost and time savings.
> Regression tests will be automatically evaluated Figure 2 shows an implementation of a regression test in a Mod-
el-in-the-Loop test environment. Functions are modeled in Simu-
A key aspect of regression testing is the quality of the comparison link/Stateflow, while the Simulink Design Verifier generates the
of a modified functional model with its previous version. One mea- test cases. In principle, other modeling tools could also be used,
sure of this quality is code coverage, which is why comparing dif- provided that they can be obtained with test case generators.
ferent versions of a functional model requires the greatest possible The “Test Cases” block shown in the diagram (Figure 2) contains
coverage. In test cases related to requirements, greater code the automatically generated test cases and stimulates the “Test

Figure 2:
Setup of a Model-
in-the-Loop test
environment for
regression tests
in MATLAB/Simu-
link. A script
generates test
reports and auto-
matically adapts
their output
format

2/25

19 Press Book_Seite_2-24_2-27.indd 3 09.02.2010 13:27:06 Uhr


Unit” system under test. This represents the modified functional advantage here is that the test cases do not need to be manually
model. The “Expected Results” block contains the reference outputs re-created.
from the previous version of this functional model. In the “Regres- A tester wanting to re-use the test cases may find that changing
sion Test Analyzer” block, the newly generated outputs of the modi- the test environment from Model-in-the-Loop (MiL) to Hardware-
fied functional model are compared to the reference outputs at in-the-Loop (HiL) also shifts test boundaries. Test cases in the MiL
each step of the simulation. After the test run, a script automati- test environment refer back to the logical input and output signals
cally creates the test report and adapts it to the desired output for- of the functional model. Test cases in a HiL test environment, on
mat. In this case, the output format matches a CANoe test report by the other hand, require physical signals, e.g. CAN signals, to stimu-
Vector. If the evaluation finds a difference in the outputs, checking late the system and evaluate system behavior. It is therefore neces-
must indicate whether the difference is acceptable or whether it is sary to transform the test cases, which involves mapping logical
an error. signals to associated CAN signals (Figure 3).
The iterative approach presented here is an efficient way to sup- Also, when performing a transformation it must be remembered
port continuous improvement and adapt the functional model to that test cases in the modeling tool do not necessarily have the
new requirements. It also improves the quality of the functional same data structure or data format as test cases in a tool for HiL
model. In addition, verification at each step in the development tests, e.g. in CANoe.
process ensures that no new errors have been introduced, further In practice, XSLT Stylesheets might be used to perform such a
improving quality. Developing functions with this model-based transformation, for example; this assumes that test cases can be
approach will make test cases available. The goal is to not only use exported from the modeling tool in XML format. Before the test
these test cases for regression testing of functional models, but cases may be transformed to suitable executable test scripts for the
also for later test phases in the automotive software engineering given HiL test environment, an intermediate step is necessary:
process, such as in ECU acceptance testing. mapping the signals, e.g., using an Excel table. Visual Basic for
Applications replaces the relevant items in the XSLT Stylesheet
Re-using test cases in ECU acceptance tests where the mapping is implemented. Finally, the transformed test
cases are linked and automatically executed in CANoe. An automat-
The goal of the acceptance test is to verify that software functions ically generated test report helps in evaluating the test results. All
that suppliers implement in ECUs behave as defined in the specifi- necessary steps in this tool chain can be automated, which yields
cation. To perform an acceptance test, suitable test cases must be time and cost savings.
created which test the specified functionality. Clearly, one poten- Acceptance testing with reusable test cases now tests both the
tial way to reuse the test cases generated from model-based devel- software integration and the hardware-software integration. Test-
opment is in a Hardware-in-the-Loop test environment. The ing 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

19 Press Book_Seite_2-24_2-27.indd 4 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
Wolfgang Hartig (M. Eng.),
the complete software system with the ECU hardware is tested in obtained his Master of Engineering degree in
the HiL test environment. This verifies the entire implementation Electrical and Microsystems at the University
in the ECU. of Applied Sciences in Regensburg. He con-
ducted his Master’s thesis work at Vector on
the topic: “Study of the potential uses of
Summary and Outlook automatically generated test cases starting
from software models“. Today, he is
employed in the area of Technical Consulting
Powerful new test case generators are now commercially available and Engineering Services at Vector. E-mail:
which make it possible to conduct efficient regression tests during wolfgang.hartig@vector-informatik.de
model-based development of vehicle functions without any addi-
Albert Habermann (Graduate Physicist),
tional effort. Test cases generated can be re-used in later test
served as an advisor for the Masters thesis of
phases of the automotive software engineering process, such as in Mr. Hartig as part of his work in Technical
ECU acceptance testing. This requires converting the test cases by Consulting and Engineering Services at
Vector (with a focus on model-based SW
means of a suitable transformation to produce test scripts for the
development and testing). Today, Mr. Haber-
specific HiL test environment. mann is project manager for the eASEE
A method-based approach to testing may be applied to model- process tool in the Customer Service area
based function development with functional descriptions in at Vector.
E-mail:
MATLAB/Simulink. Use of model-based test methods is being stud- albert.habermann@vector-informatik.de
ied in ongoing research projects. For example, the goal of the
VitaS3 research project at the University of Applied Sciences in Jürgen Mottok, (Prof. DSc.),
teaches computer science at the University of
Regensburg is to determine the extent to which formal and semi- Applied Sciences in Regensburg. His areas of
formal description languages such as the Object Constraint Lan- teaching include: Software engineering, pro-
guage (OCL) and temporal logic methods can be used to generate gramming languages, operating systems and
functional safety. He directs the Laboratory
test cases via model transformations [2]. The use of formal descrip-
for Safe and Secure Systems (LaS3), is a mem-
tion techniques is prescribed in the primary industrial standard for ber of the advisory board of the Bavarian
functional safety IEC-61508 for safety-critical systems. This Cluster of IT Security and Safety, and active
in other working committees. E-mail:
approach enables virtual integration of vehicle functions.
juergen.mottok@e-technik.fh-regensburg.de

Literature references:
[1] Liggesmeyer, P.: Software-Qualität, 2002
[2] Laboratory for Safe and Secure Systems LaS3, VitaS3 research project,
(www.las3.de/englisch/forschung/forschungsprojekte.html)

2/27

19 Press Book_Seite_2-24_2-27.indd 5 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 air-
bag control unit is responsible for proper operation of the entire occupant restraint system, consisting of all sorts of air-
bags, belt tensioners, sensors and switches. Even during product development, numerous validation tests are indispen-
sable 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 generate various error states of the airbag system to study the
control unit. Airbag systems must operate absolutely error-free, ECU’s behavior in such situations. The desire to improve test quality
and so they are subject to the most stringent safety requirement and automate test sequences in testing that supports development
level: ASIL Level D. It requires continual monitoring of all of the motivated Bosch to subcontract the development of a compact,
system components involved such as squibs, sensors, switches and mobile airbag test system. The goal was to obtain a flexible system
the airbag control unit itself. Fault conditions are stored in fault that implements the requirements of early test phases more cost-
memory and can be read out in the service garage. effectively than powerful HIL systems (Figure 1), and which is
The test system presented here focuses less on crash-triggering well-suited to worldwide use at all Bosch development sites for air-
tests, and more on validation of software requirements derived bag systems.
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 system’s capabilities is to

2/28

20 Press Book_Seite_2-28_2-31.indd 2 09.02.2010 13:24:36 Uhr


Requirements of the new test system generating short circuits between lines and to different voltages,
for example. Resistor decades simulate the operating ranges of
In the framework of project services, Vector Informatik developed squibs and seatbelt switches in this application. The test system
the test system software and integrated the test hardware. The must also simulate connection of the wrong lines as well as over-
project-specific hardware was designed and built by TBM Software- voltages and undervoltages. This involves use of an integrated volt-
Entwicklung & Elektronik (TBM). In the joint planning phase, it was age supply to run through various individually programmable volt-
determined that software and hardware requirements for the new age curves. Afterwards, a check is made to determine whether the
system would vary widely, because it would have to handle many airbag ECU’s internal monitoring correctly identifies the error
Bosch projects for different OEMs, vehicle lines and variants. The states.
goal here was to find a reasonable compromise that would allow a Another important requirement is configurability of the test sys-
majority of the software requirements to be validated for the ECUs. tem. The number, names and assignments of the pins used, as well
A key requirement is simulation and monitoring of the ECU’s as the number and type of squibs and seat belt buckles vary with
immediate environment. This environment consists of squibs, each project. These aspects must be taken into consideration, so
switches, peripheral acceleration sensors, warning lamps and the that the test system can be conveniently used in different projects.
CAN bus. To simulate line errors, the system must be capable of
Automatable tests, easy operation and flexible test
software

Vector’s 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 appli-
cation 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
Figure 1: functions. This makes additional functions available to users,
Use of the new test system in the V-Model including automatic reporting (Figure 2).

Figure 2:
Layout of the test
system

2/29

20 Press Book_Seite_2-28_2-31.indd 3 09.02.2010 13:24:37 Uhr


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

Figure 3:
Components of the CANoe
configuration

2/30

20 Press Book_Seite_2-28_2-31.indd 4 09.02.2010 13:24:38 Uhr


VALIDATING SOFTWARE REQUIREMENTS BY EFFICIENT AIRBAG ECU TESTS

Summary and outlook


David Oberschmidt (Dipl.-Ing.)
studied Physics at the KTH Stockholm. Since
The new airbag test system for software requirements testing 2002 he has been employed at Robert Bosch
exceeded expectations in fulfilling project goals. After an initial GmbH (in the Airbags area until 2006, and
since then as technical project leader for ESP
automation effort, the system enables significantly shorter test application projects in France).
times despite the much higher number of test cases. In addition, E-mail: david.oberschmidt@fr.bosch.com
early implementation of automated tests during software develop-
ment means that errors in the airbag ECUs can be detected and cor-
rected more quickly. Subsequent validation stages build upon a
high level of software quality. Global use of a uniform test system
Frank Böhm (Dipl.-Ing. (FH))
for software validation levels at all Bosch sites for developing air-
studied Automotive Engineering at the Uni-
bag ECUs makes it easy to reproduce faulty behavior independent versity of Applied Sciences at Esslingen. He
of the site. Excited about the many capabilities and potential of has been employed at Robert Bosch GmbH
since 2002, where he works as a development
CANoe, Bosch is already considering further extensions of its air-
engineer in the Airbag area, specializing in
bag test system. the areas of Test Automation and Test
Tooling.
Tel. +49-711/811-20939
An airbag triggering process consists of a sequence of highly
E-mail: frank.boehm@de.bosch.com
precise, interrelated and coordinated individual actions. Sen-
sors supply information on the vehicle’s speed, transverse and
Dr. (rer. nat.) Martin C. Geisler
longitudinal acceleration values and rotational movements.
studied Physics at the Ruhr University at
The airbag ECU applies other parameters in its computations – Bochum, Germany, and at the University of
such as weight distribution on seats, states of seatbelts, belt Sussex, England. He has worked at the Riken
tensioners and switches – to determine which airbags should Research Institute in Saitama, Japan, and he
earned his doctorate degree at the Max-
be ignited, at what times and with which strength. The air bags Planck-Institute for Solid State Research in
are only activated for a short period of time, so precise igni- Stuttgart. Since 2005, he has been employed
tion time is a crucial parameter. Another important parameter at Robert Bosch GmbH as sub-project leader
and later as team leader for software valida-
is the speed at which the bags fill, which can be influenced by
tion in the Airbag area.
the use of different ignition pills. The ignition pills are pyro- Tel. +49-711/811-24324
technical propellant charges that generate a lot of gas in a E-mail: martin.geisler2@de.bosch.com
short period of time.
Katja Hahmann (Dipl.-Ing.)
studied Electrical Engineering at the Techni-
cal University of Chemnitz. Since 1997 she
has been employed at Vector Informatik
GmbH in Stuttgart where she is group man-
ager 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

20 Press Book_Seite_2-28_2-31.indd 5 09.02.2010 13:24:38 Uhr


21 Press Book_Seite_3-00_3-07:Press Report 2 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 con-
cepts 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 present-
ed 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 This trend has not been without consequences for diagnostics ei-
The fast growth of electronic functions in vehicles dur ing the sec- ther. Twenty years ago the diagnostic capability of a function was
ond half of the 1980s at first led to many insular solutions that pre- not even considered until shortly before production star tup. Today
vented comprehensive concepts from taking hold in the area of basic diagnostic functions usually exist as early as in the B-Sample.
electrical/electronic architectures. At the beginning of the 1990s a Handling of diagnostics has improved signif icantly. In the times of
consolidation phase began that was marked by development of flash codes the process required that users tediously count the
electrical/electronic structures and associated networking topolo- number of flashes and convert them to error codes based on print-
gy from a comprehensive perspective. This meant that electri- ed-out tables. Today testers output instructions in clear text.
cal/electronic content and its networking could claim an undisput- In the past it was possible to do without tool support entirely. To-
ed position in the vehicle. The recognition that many functions day power ful diagnostic tools are an everyday reality. It is possible
could only be implemented sensibly with the help of electronics al- to create the diagnostic specification, generate ECU-specif ic code
so prevailed. So the image of electronics transformed from being a and parameter ize the diagnostic tester utilizing the “single source
necessary evil to being a key to new, interesting and innovative principle”. A precondition is that specification of diagnostics must
functions. The three bus nodes in commercial vehicles in 1989 have be shifted to the beginning of the development process (Frontload-
become more than 70 today in similarly equipped vehicles; see Fig- ing); see Figure 2. The ODX format also enables cross-OEM exchange
ure 1. The underlying software amounts to about 10 million lines of of diagnostic data.
programming code.

Figure 1:
Development of electronic net-
working based on the example of
the E-Class model series W210
(1995) and W211 (2002).

3/0
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 2

From proprietary diagnostic tool to standard tool chain the inter face between the runtime system and the test application
The developing trend of diagnostic tools is similar to the trend of per ISO 22900-3 (ASAM MCD-3D, D-Server API). Each of the pro-
electronics in the vehicle. Back in 1990 automotive OEMs created gramming inter faces mentioned are available to the user as soft-
their own tools in-house. Specialists in dif ferent departments cus- ware librar ies. Also wor thy of mention are the diagnostic-relevant
tomized their tools precisely to their requirements and specif ic ap- standards per SAE J2534 and in the context of AUTOSAR standardi-
plications. This produced individual in-house solutions within each zation AUTOSAR WP4.2.2.1.4 (DCM, DEM). Fur thermore, the UDS di-
OEM and even for dif ferent process steps. agnostic protocol per ISO 14229-1 (Unified Diagnostic Services on
CAN) will gradually replace older protocols such as the K-Line per
About 1995 automotive OEMs came around to a new way of think- ISO 9141-2 and “KWP2000” as well as “KWP2000 on CAN”; see Fig-
ing, i.e. that they wanted to once again focus more on their core ure 3.
business. Accordingly, tool development was outsourced to exter-
nal service providers. Initially, these outsourcers produced special Character istics of modern diagnostic solutions
in-house solutions as well, but they succeeded in reducing the dif - The development of comprehensive, homogeneous diagnostic solu-
ferences between tools and standardizing existing solutions within tions is a challenge. It requires studies and ef forts on many dif fer-
cer tain limits. This trend continued until open, nonproprietary di- ent levels, in order to satisfy all requirements under one roof. On
agnostic tools became available on the market in the year 2000. For the one hand, this involves rationally creating power ful diagnostic
users, the route of product licenses is noticeably more cost-ef fect- systems and on the other hand developing a user-friendly ap-
ive than assuming responsibility for developing and maintaining proach. It is only possible to realize these two goals with a univer-
proprietary tools in-house. Moreover, there are shared benefits due sal, complete and practical diagnostic tool chain. Solutions must be
to synergistic ef fects of the combined experience of other market specified, implemented and documented for both the overall vehi-
par ticipants. In 2005 the tools began to support general standards. cle diagnostic system and diagnostics for specif ic ECUs. Fur ther-
Contemporary tools of fer standardized inter faces that can be more, consistent management and distribution of diagnostic data
seamlessly integrated into existing tool chains. must be assured. That is because the applications of diagnostic so-
lutions range from the development process with its many dif ferent
Old and new standards for diagnostics areas of focus, to quality assurance in production and finally diag-
Standards currently in the spotlight include the diagnostic data nostics in the service garage.
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

Figure 2:
Diagnostic tool chain based on
single-source principle utilizing
standardized exchange for mats.

3/1
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 3

The above-named standards serve as a foundation and building the standardization committee. For suppliers, for example, it is cru-
blocks for implementation of such comprehensive diagnostic sys- cial that they be capable of handling projects for dif ferent automo-
tems. They benefit individual market par ticipants without restrain- tive OEMs with one and the same diagnostic tool. And to accomplish
ing natural competition. Besides achieving cost reduction, stand- a gentle migration from the existing solution to the standardized
ardization brings the user additional advantages such as inter- diagnostic system, special temporary measures are of ten necessary
changeability of products, components and data. It can be expect- dur ing a transition time. In the introductory phase for new stand-
ed that even more standards will be created in the future, which in ards it is impor tant to support multiple parallel versions in a con-
turn will af fect the tools used. sistent way.

Practical capabilities are trump Openness for progress and innovation


In introducing modern diagnostic tools, focus on the needs of users Even if standardization and innovation seem to be two irreconcila-
is of fundamental impor tance for their acceptance. The user should ble goals at first glance, automotive electronics is character ized by
not be confronted with the full complexity of the standards. Rather continual development. Progress is one of the most impor tant key
it makes sense to present a diagnostically-driven perspective of the per formance indicators for automotive OEMs and suppliers. There-
data to the user. Special knowledge of the underlying data format fore expandability of currently used tool chains is always in de-
should not be necessary. It is also impor tant to optimize typical re- mand, so that innovations and functionalities of future standards
curring work steps by guiding the user in per forming the necessary can be utilized or tested in advance.
tasks correctly, consistently and with time savings. In par ticular
this includes avoiding redundant processes and wherever possible Enough ideas and tasks still remain to ensure that in the future au-
reusing already existing data material. tomotive electronics, networking and diagnostics will continue to
improve on the achievements of the last 20 years and adapt them to
Flexibility in handling customer-specif ic features new requirements. It must be assumed that the pace of innovation
In all of the ef forts to achieve uniformity and standardization in will accelerate even more, and even closer collaboration will be
creating power ful tools, it is impor tant not to lose sight of flexibili- necessary between automotive OEMs, suppliers and tool producers.
ty. Current diagnostic standards of fer a cer tain degree of latitude This also per tains to a common approach in dealings with legisla-
that can be exploited to address supplemental requirements not tive bodies.
covered by the standard. These include customer-specif ic features
and conventions or special wishes not supported by the major ity of

Figure 3:
The most impor tant applied net-
working and diagnostic technol-
ogies over the past 15 years.

3/2
21 Press Book_Seite_3-00_3-07:Press Report 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 integrated. DIOGENES, the DaimlerChrysler-specif ic description da-
Similarly, there is much future potential for diagnostics, now that it ta format, is also automatically generated and is then processed by
has succeeded in quasi evolving from a “minor appendage to func- the uniform diagnostic runtime system. The requirements and ex-
tions” to a “function in its own right”. This signifies the step from periences of other cooperation partners such as OPEL/GM and agri-
simultaneous development to integrated development, which re- cultural machine producer CLAAS have had signif icant influences
sults in even closer cooperation between diagnostic and functional on the CANdela approach too. In the meantime Vector has also been
developers. For the diagnostic system a model-based approach also working together with companies such as Fiat, Ford and numerous
came to fruition, which applies knowledge acquired from FMEA automotive suppliers worldwide.
(Failure Mode and Ef fects Analysis) for example. Tools like DaVinci
and CANdelaStudio from the Vector Informatik company, IQ-FMEA Handling special project-specif ic features with templates
and Matlab/Simulink enable diagnostic design strategies utilizing a In formal diagnostic description templates, or just templates, are
universal and automated tool chain, from modeling tool to author - impor tant services for taking into consideration specif ic require-
ing system. ments of the manufacturer, project and vehicle model. Fully specify-
ing diagnostics at a very early time prevents most misunderstand-
Diagnostic developments at DaimlerChrysler ings, errors and iterative optimization loops in the diagnostic de-
DaimlerChrysler AG and Vector Informatik GmbH have expanded velopment process. The use of CANdela is firmly established in the
their close cooperation over the past several years, including in the development process at DaimlerChrysler. ECU suppliers not only de-
area of diagnostic tools. Easy and convenient use of tools and de- velop the diagnostic functions in the ECU; they also supply the as-
scription of all diagnostically-relevant data in a uniform format are sociated formal descriptions. Of ten standard software components
impor tant principles of their joint projects. Data and diagnostic are used to implement diagnostics in the ECU. The diagnostic com-
functions are only formally specified once in the solutions, which ponent CANdesc (CAN diagnostic embedded software component)
are based on the “single-source principle”. Therefore they are uni- can be automatically generated from the CANdela data; see Figure
versally available to all project par ticipants and suppliers in ma- 2. This gives ECU and vehicle producers a way to achieve uniform
chine-readable XML description files; see Figure 2. implementation of the diagnostic protocol across all products.

In CANdela (CAN diagnostic environment for lean applications) ODX exchange format and UDS diagnostic protocol
Vector Informatik structured its diagnostic product line-up with The international standard ODX (Open Diagnostic Data Exchange)
suf ficient flexibility so that OEM-specif ic export formats could be serves as the standard for exchanging data and nearly all diagnos-

Figure 4:
Complex bus networking in the LEXION
combine har vester.

3/3
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 5

tic information between individual tools, as well as between auto- In its diagnostic development process CLAAS runs through the V-
motive OEMs and suppliers. It is being developed within the ASAM Model with the CANdela tool chain. CANdelaStudio is used to create
standardization body (Association for Standardization of Automa- the specification of diagnostic functionality consistently. The cap-
tion and Measur ing Systems) and is expected to be released as ISO tured data are used directly to generate the ECU-specif ic diagnostic
standard 22901-1 in 2007. DaimlerChrysler plans to replace its own software component with CANdesc. To parameter ize the tester
DIOGENES format by ODX on future projects. CLAAS utilizes ODX data exported by CANdelaStudio, Figure 5.
The CANdela approach handles import and export of ODX data and For a half year now CLAAS has also been using CANoe Option DiVa
enables a smooth transition from proprietary formats to the stand- (Diagnostic Integration and Validation Assistant). DiVa makes it
ardized exchange format for suppliers. Moreover, the Vector Tools possible to automatically generate and execute reproducible test
CANoe, CANape, CANdito and CANdelaStudio support the new UDS cases for implementation and integration of the diagnostic proto-
diagnostic protocol (ISO 14229), which DaimlerChrysler is introduc- col. Serving as requirements are internal CLAAS test specifications
ing in all of its corporate divisions on each successive model change and the diagnostic database. Suitably configured, DiVa permits test
beginning with the current C-Class where it will replace the previous scenar ios of var ying depth and intensity, e.g. comprehensive tests
KWP2000 protocol. DaimlerChrysler is relying on the standard ODX-F or just tests of specif ic services. The program outputs detailed
format for describing the flash data too. This is done with the flash HTML test reports for error analysis purposes. In the future, auto-
data management tool CANdelaFlash from the CANdela product line. mated testing with CANoe Option DiVa will be used for all CLAAS
ECUs.
Automating tests at har vesting machine producer CLAAS
At Europe’s leading producer of har vesting machines, CLAAS, ef fi- Joint diagnostic project by DaimlerChrysler and Volkswagen
cient development of diagnostic systems plays a key role. In a com- A joint project pointing the way to the future and simultaneously
bine har vester there are up to four highly complex bus systems op- serving as a test case for new diagnostic standards and exchange
timized for agricultural tasks; see Figure 4. formats was the joint development of the new transporter genera-
tion “Sprinter” and “Crafter” by DaimlerChrysler AG and Volkswagen
The challenges facing the agricultural vehicle diagnostic system are AG. The project executed under the name “Phoenix” started in the
enormous: 350 connectors with 3,000 electrical contacts, 3,000 m year 2003 and reached its inter im conclusion in mid-2006. Techni-
of copper lines, up to 25 ECUs or CAN nodes and numerous opto- cally, the Sprinter and Crafter vehicles are for the most part identi-
electronic machine guards, potentiometers, valves, ser vo-drives cal and will be produced in var ious body configurations, weight
and speed sensors must all operate properly and work together. 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
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 6

VE HI CLE DI AG NOS TICS – THE WHOLE STO RY

wigsfelde and Düsseldorf. Besides dif ferences in body design, other ternal suppliers were involved, there was as yet no practical experi-
key dif ferences lie in each vehicle’s brand-specif ic power train. ence with the new ODX standard, and a tight schedule had to be
maintained. In the Phoenix project the per formance of the ODX
The initial idea for a diagnostic concept was to “translate”, so to standard was put to the test in a challenging large project and it
speak, the Sprinter diagnostic data from DaimlerChrysler to VW via passed successfully.
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 Future visions: Where does the road lead?
speaks a dif ferent language due to incompatible diagnostic philos- With relentless progress in standardization many things are simpli-
ophies. However, this strategy was rejected in favor of modifying fied, and it is possible to come to grips with new challenges. As ev-
the service tester and exchanging diagnostic data by ODX. Stated in er, natural competition will generate a great deal of dynamism in
somewhat simplified form, an ODX converter now processes the ODX future development. Of course, it is impossible to predict exactly
diagnostic data generated by CANdela and uses them to prepare the what ef fects this will have on vehicle electronics and diagnostic
ODX data for VW, Figure 6. Existing components of the VW service systems of the future. However it can be stated with cer tainty that
tester are not replaced, rather they are supplemented by other the signif icance of Internet technologies will continue to grow, as
functions needed for a migration. is also the case in many other technological areas. For example,
“Diagnostics-over-IP” is conceivable. Initial studies with Ethernet
ODX: Trials passed successfully and TCP/IP are already under way in conjunction with FlexRay gate-
In this first joint diagnostic project the par ticipating automotive ways. If vehicles take on the position and functionality of a HTTP
OEMs were able to acquire valuable experience, even though they server from an information technology perspective, general identi-
were confronted with dif ficult constraints. It was necessary to deal fication via IP addresses might make sense, for example, and this
with fundamentally dif ferent diagnostic philosophies involving dif - would make Vehicle Identification Numbers super fluous. Standardi-
ferent languages for coding, parameter ization and control. Fur - zation will continue to advance in test modules and test proce-
thermore, all components contained in the diagnostic development dures, and re-use in development, production and the service ga-
process, such as export to ODX and the ODX standard, were still just rage will become commonplace. Similarly, error messages in clear
in the development stage. Numerous internal departments and ex- 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
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 7

for this are diagnostic design concepts with universal and automat-
ic 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] Kühner, 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 diag-
nostic software”, Vector Congress 2006
[3] Johanson, D.: “Introducing ODX diagnostics in a OEM joint venture pro-
ject”, Vector Congress 2006
[4] Rätz, C.: “What is the market demand for diagnostic solutions?”, Vector
Congress 2006
[5] Stimmler, S. and Rätz, C.: “On a solid basis – Ef ficient development of di-
agnostic functions in the automobile”, Automotive Electronics 2/2005

Helmut Frank
(Graduate Engineer)is a Business Develop-
ment Manager at Vector Informatik responsi-
ble for the Diagnostics product line.

Uwe Schmidts
(Graduate Engineer) is a Marketing Coordina-
tor at Vector Informatik whose responsibili-
ties include the Diagnostics product line.

3/6
21 Press Book_Seite_3-00_3-07:Press Report 2 09.02.2010 13:05 Uhr Seite 8

Vehicle
Diagnostics
Increase your Development
&GæDJFODZFWFONPSF
Distr. Systems
In diagnostic development, benefit from solutions that span the
Development

entire development process. Increase your efficiency and improve


your quality by using optimally tuned and coordinated tools.
ECU

The CANdela product family supports you by:


> Frontloading – early high-quality specification of diagnostic
Diagnostics
requirements at the beginning of the development process
> Single source principle – Re-use of created diagnostic data in
all process steps
Calibration
> Automated code generation, validation and test
ECU

> Diagnostic tester ideally configured for your area of application


> Open interfaces and data exchange, e.g. via ODX
Software
Vector diagnostic tools help you to reduce the effort required
ECU

in specification and data supply tasks by a factor of up to 7*.


In automated validation, improvements by a factor of 4 to 20*
Management are possible – depending on the project phase. The bottom line
Process

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

Vector Informatik GmbH


Ingersheimer Str. 24
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 implementa-
tions 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 mastery of this complexity, accelerate the development process


and guarantee proper operation of the installed ECUs. Particularly
One consequence of strong competition in the global automotive in the area of diagnostic functionality provided by the ECU, it is
market is that it is forcing a shortening of development cycles. crucial that diagnostic services are correct. They transport informa-
Another is that the complexity of the electronic networking archi- tion that helps mechanics in the service garage to quickly deter-
tecture is continually increasing. Key goals in replacing conven- mine the cause of a fault and correct it. This information must make
tional systems by electronically controlled systems relate to cost it possible for the mechanic to decide which component is the
reductions, a high level of safety and reliability as well as better source of the problem and what needs to be replaced to restore full
manageability. Despite all of the benefits, it must not be forgotten operational readiness. If this is not assured, the result may be erro-
that increased numbers of electronic components in vehicles can neous replacement of properly operating units [1], which causes a
increase the probability of electronics-related faults. Since reliabil- rise in warranty costs and a decline in customer satisfaction.
ity is an important criterion for customers when purchasing a new The E/E architecture of the Opel Insignia consists of several Con-
vehicle, it is essential to introduce new methods that enable troller Area Network (CAN) and Local Interconnect Network (LIN)

3/8

22 Press Book_Seite_3-08_3-15.indd 2 09.02.2010 13:26:37 Uhr


bus systems [2, 3]. All bus systems are accessed via a central diag- Validation process and tool environment at General
nostic port (DLC), see Figure 1. Communication is defined by a GM- Motors Europe
specific protocol. This GM diagnostic specification is based on
KWP2000 [4] and the CAN 2.0A standard. It contains all diagnostic In development of the Opel Insignia, GME introduced the DiVa tool
services allowed for addressing an ECU’s diagnostic system to from Vector Informatik for the first time. DiVa automates genera-
obtain diagnostic information. These services are then output by tion and execution of diagnostic tests.
the diagnostic tester to establish diagnostic communication. As Figure 2 shows the tool environments for the Opel Corsa and
soon as a request is sent, the addressed ECU(s) react with either a Opel Insignia. In both cases, CANoe [5] is used as a test tool. While
positive or negative response: validation is largely performed manually in development of the
> Positive responses contain the diagnostic information requested Corsa, in development of the Insignia the vast majority of testing is
by the diagnostic device. If there is a lot of diagnostic informa- covered by fully automated tests.
tion, the response may include multiple message frames. Figure 3 shows a typical diagnostic validation process for an ECU
> Negative responses contain a clearly defined Negative Response performed by a test engineer at GME. Development of the ECU soft-
Code, which gives information indicating the reason for the neg- ware is subdivided into several phases. At the beginning of an ECU
ative response. Negative Response Codes are given in accordance development, the focus is more on implementation of ECU func-
with the GM Diagnostic Specification. tionality than on diagnostic services. The latter are then elaborated
and developed in subsequent software versions. As shown in Fig-
The received responses must enable technicians to determine the ure 3, with introduction of the Phase 1 (SWR 1) software version,
cause for a fault, so that they can perform the right tasks to solve only a small number of diagnostic services are implemented. The
the problem. use of diagnostic software components at GME (CANdesc) has made
Therefore, the success of a fault correction in the service garage it possible to implement a portion of the diagnostic content early
depends considerably on the accuracy and precision of the data at the start of development, and as a result it is integrated in the
output by the diagnostic system. Proper implementation of diag- ECU earlier (Figure 3).
nostic services is essential in performing quick and professional The number of diagnostic functions to be tested grows with each
service or maintenance to the satisfaction of customers. Diagnos- development cycle. Once all diagnostic services have been imple-
tics also plays an important role in end-of-line testing: it is used to mented, regression tests are performed (SWR 7). If no more faults
program ECUs and assure product quality. That is why comprehen- are reported in diagnostic services at that development stage, the
sive validation of diagnostic functionality is absolutely necessary. ECU is production mature in the execution of diagnostic services.

Figure 1:
E/E architecture
and diagnostic
communication on
the Opel Insignia

3/9

22 Press Book_Seite_3-08_3-15.indd 3 09.02.2010 13:26:37 Uhr


Since a test engineer normally tests a number of different ECUs From specification to test execution and report
simultaneously, without adequate tool support it is impossible for evaluation
the engineer to perform the large number of tests necessary to
cover all of the implemented diagnostic services of the individual As shown in Figure 2, DiVa represents the link between
software versions. As a result, only newly implemented diagnostic CANdelaStudio (diagnostic specification) and the proven validation
services are tested in-depth, and test engineers perform represen- tool (CANoe). DiVa can be seamlessly integrated in the existing and
tative regression tests for previously integrated individual services established GME tool chain. Test cases for checking the individual
based on their experience. By using a suitable automation tool, services are automatically derived from the CANdela diagnostic
more tests may be performed in validation while simultaneously specification (CDD file). The generated code is based on the CANoe
reducing effort. programming language CAPL (Communication Access Programming
Language) and can therefore be examined at any time. If problems
Requirements for the validation tool occur, the test engineer can intervene in the automated test
sequence and troubleshoot their causes (transparency). Further-
A tool for automated diagnostic validation must satisfy the follow- more, CANoe’s logging functions enable traceability and evaluation
ing requirements: of the diagnostic data flow on the CAN communication level.
> Seamless integration in the existing tool chain The following steps are necessary to conduct a test with DiVa:
> Transparency and reproducibility: The test engineer must be able > Select the ECU and its variant
to track the executed tests and repeat them. > Configure the test
> Conformity to existing testing methods at General Motors: The > Generate the test
tool must support existing test methods. In the diagnostic area, > Add the generated test module to the CANoe test environment
the GM Diagnostic Specification already defines mandatory test > Execute the tests
procedures for GMLAN Diagnostic Services of the ECUs. > Evaluate the test report
> Expandability by the test engineer
> Automatic generation of test cases: The specification must exist The user can modify test constraints in DiVa at any time. Among
in a machine-readable format to enable this. 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

22 Press Book_Seite_3-08_3-15.indd 4 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 Test coverage
enables synchronization to the new specification while preserving
previously defined settings. From a technical perspective, DiVa gen- Automating the tests extends test coverage and simultaneously
erates CAPL code for the CANoe test module in order to test all diag- shortens the time needed for test execution. The extent to which
nostic services supported by the ECU. To assure conformity to the GM DiVa covers the test procedures described in the GM Diagnostic
diagnostic specification, the DiVa extension maps the test proce- Specification is described below. The quality and number of gener-
dures of the GM standard. The test generation process produces a ated test cases depend in large part on the completeness of the
detailed description of the generated test cases, CAPL test codes for machine-readable diagnostic specification (CDD file). All generated
the CANoe test module and the associated CANoe test environment. tests are derived from it.
A total of about 350 test sequences are defined in the GM Diag-
Test execution and report evaluation nostic Specification. The test sequences cover both “good case” and
“bad case” tests. A large share (approx. 80 %) of the test procedures
After the test has been generated, the user opens the generated are covered by fully automated tests in DiVa. An application-specific
test environment in CANoe and starts the test. The test duration user input is required for 45 (15 %) of the test procedures defined in
depends on the complexity of the diagnostic specification and the the GM Diagnostic Specification. In such cases, DiVa pauses test
user-defined test scope that is selected, and it may vary from just a execution and asks the user to put the ECU in the required state.
few minutes to several hours (Table 1). At General Motors, the The remaining 5 % of test procedures are not supported by DiVa and
CANoe test environment serves as a joint platform for test automa- must be tested either manually or by other means. This includes
tion and simplifies reuse of existing GM test programs. For exam- tests that would put the rest of the test procedure at risk (e.g. gen-
ple, end-of-line flash test procedures are also programmed in the erate EEPROM errors and detect them) or would cause long-term
CANoe programming language CAPL. To simplify analysis by the test changes to the ECU (e.g. an ECU without calibration data).
engineer, test reports are structured according to the GM diagnos- Testing depth is further enhanced by including execution of
tic specification. Figure 5 shows a typical test report. additional non-GM-specific test cases.

Figure 3:
Scope of diagnos-
tic functions in
various phases of
ECU development
at GME

3/11

22 Press Book_Seite_3-08_3-15.indd 5 09.02.2010 13:26:38 Uhr


Comparisons made at GME between validation for the Opel Corsa By using DiVa, execution and evaluation times were shortened
and for the Insignia conclude that DiVa shortens test execution considerably on the Opel Insignia compared to the Corsa. In the
time enormously by predominantly automated execution of all gen- studied case, 3- to 5-fold improvement was attained (Figure 6). In
erated test cases, Figure 6. Table 1 shows a summary of execution particular, the time savings was enormous for ECUs with a large
times and the number of generated test cases for ECUs in the Opel number of diagnostic services. If one considers later development
Insignia. Often, manual tests can only be performed sporadically phases such as SWR 6 or SWR 7, the time needed for evaluating test
due to time demands. Therefore, test results largely depend on the results is reduced even further. This can be traced back to the
experience of the test engineer and the amount of time available. smaller number of failed test cases in the more mature implemen-
At GME, DiVa enables both complete testing of ECUs per diagnostic tation. This trend continues in each new phase up to the production
specifications and greater test coverage in all development stages. launch. The production ready ECU must not exhibit any defects;
consequently, the evaluation time is equal to the execution time.
Economic aspects and efficiency increases In this stage of Opel Insignia development, depending on the com-
plexity of the ECU, efficiency might be increased by a factor of
When a tool is introduced, its economic benefit is a primary consid- 20–40.
eration. The new Opel Corsa is very successful on the market, and The cost of the new solution is low, since all that is needed are
there are no negative reports of diagnostically-related electronic licenses for DiVa. A user at GME who is familiar with CANoe can per-
problems. That is why the manually performed validation process form DiVa tests – without prior training. Additional hardware is not
on the Opel Corsa was selected as a reference project. In contrast, required for test execution, since DiVa utilizes the available CAN
on the new Opel Insignia, DiVa was being used as the primary tool infrastructure via CANoe.
for validation of diagnostic services. It was used to automate a
large share of validation tests for the first time. For comparison Limitations on automatic of test case generation and test
purposes, the study evaluated the time required for test execution execution
and evaluation in the validation phase, based on representative
ECUs. The values given are based on implementation level SWR 5, Even if automated tools are better than manual test strategies in
Figure 3. Most services have already been implemented at that terms of test scope and time effort, automatic test generation does
point, and a large number of failed test cases had already been run into limitations:
captured. Figure 6 shows validation effort in hours for manual > Quality of the specification: Since the specification represents
testing on the Opel Corsa and automated testing on the Opel the basis for generating test cases, completeness and accuracy
Insignia. 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 con-
straints in DiVa
(here: configura-
tion of services)

3/12

22 Press Book_Seite_3-08_3-15.indd 6 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 vali-
dation, compared
to automated vali-
dation of diagnos-
tic services on the
Opel Insignia
(execution and
evaluation time)

3/13

22 Press Book_Seite_3-08_3-15.indd 7 09.02.2010 13:26:39 Uhr


requirements of the General Motors diagnostic infrastructure
Dr. Philipp Peti
(GGSE-I) [6] studied Computer Science at the Vienna Uni-
> Reproducibility: Due to the non-deterministic properties of CAN versity of Technology. He earned his doctor-
communication in a vehicle, certain error situations are very ate degree in Computer Science, also at TU
Vienna. Dr. Peti is a development engineer in
difficult to reproduce in testing. the “Global Systems Engineering” group at
> Secondary fault: In case of error, the automated test tool – in General Motors Europe, located in
contrast to a test engineer – cannot distinguish between an Rüsselsheim, Germany.
initial fault and a secondary fault.
> User interaction: In application-specific tests it may be neces-
sary to put the ECU in a state where additional hardware is
Armin Timmerberg
necessary. These cases cannot be handled fully automatically in
studied Electrical Engineering at the University
the approach described. of Applied Sciences at Wiesbaden. After his stud-
ies, he was first employed as a systems engineer
in the aftersales area at General Motors Europe.
Summary
His primary job was to implement ECU diagnos-
tics in the GM Service Tester TECH2. Since 2004,
Without the use of test automation tools, it is hardly possible to Mr. Timmerberg has been working as a develop-
achieve the desired coverage in validation of the diagnostic func- ment engineer in the “Global Systems Engineer-
ing” group at General Motors Europe, where he is
tionality of modern vehicles any longer. CANoe.DiVa from Vector responsible for diagnostic validation.
Informatik has been adapted to GM requirements to support all
established test processes, and it fits seamlessly in General Motors Thomas Pfeffer
studied Electrical Engineering at the Darm-
Europe’s existing tool chain. It is used as an automated test tool stadt University of Technology. Mr. Pfeffer is
for validation of diagnostic services on the new Opel Insignia. group manager for Diagnostics and Test
With DiVa, GME is not only shortening test duration, but is simul- Automation in the “Global Systems Engineer-
ing” group at General Motors Europe, located
taneously increasing intensity of testing by its ability to perform
in Rüsselsheim, Germany.
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 success-
ful projects, both technical and economical efficiency have been
increased significantly. Depending on the development phase and Simon Müller
studied Software Technology at the Universi-
quality of implementation, efficiency increases by a factor of 4 to
ty of Stuttgart. As a product manager he is
20 are realistic. At the same time, it is possible to satisfy the high responsible for CANoe.DiVa on the Vehicle
expectations of customers in terms of quality. Diagnostics product line division at Vector
Informatik GmbH in Stuttgart.

Literature references:
[1] Thomas, D.; Ayers, K.; Pecht, M.: The “trouble not identified” phenome-
non in automotive electronics. In: Microelectronics reliability, Vol. 42,
P. 641-651, 2002
[2] LIN Consortium: LIN Specification Package Revision 2.1, OV. 2006 Christoph Rätz
[3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991 studied Computer Engineering at the Univer-
sity of Cooperative Education at Stuttgart. He
[4] International Organization for Standardization: Keyword Protocol 2000,
works at Vector Informatik GmbH in Stuttgart
ISO 14230, 1999
as a global product line manager for the
[5] Krauss, S.: Testing with CANoe, Application Note AN-IND-1-002. Vector Vehicle Diagnostics product line division.
Informatik, 2005
[6] General Motors. GGSE ECU Diagnostic Infrastructure Requirements,
Version 1.07, 2007

3/14

22 Press Book_Seite_3-08_3-15.indd 8 09.02.2010 13:26:39 Uhr


Vehicle
Diagnostics

Automate Your Test Sequences in


Diagnostic Integration
Distr. Systems
Take advantage of automated test sequences in your integration tests.
Development

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

You benefit from:

Diagnostics > Comprehensive test coverage in implementing diagnostics for an ECU

> Quick execution of test cases and generation of a clearly structured


Calibration
test report
ECU

> Easy configuration of test contents

Software
> Full integration in the Vector tool chain.
ECU

These features help you attain maximum efficiency and quality in


Management
integrating the diagnostic protocol in your ECUs.
Process

More information: www.car-diagnostics.de/diva

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. 07 11 / 8 06 70-0
www.vector.com

22 Press Book_Seite_3-08_3-15.indd 9 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 pro-
cess. Computer-generated source code based on ECU-specific diagnostic data can dramatically decrease costs and develop-
ment 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 Most OEMs and suppliers work together in a common diagnostic
is increasing year by year. In order to take advantage of reusable development process. This conventional diagnostic development
diagnostic software components, it is necessary to examine the process is laden with inefficiencies that drive costs up and require
diagnostic software structure and identify the parts that are ECU- large efforts over several months to complete (Figure 1).
independent and the parts that are ECU-specific. The ECU-indepen- The process starts by setting up the requirements documents.
dent parts are reusable across different ECUs and can be written The diagnostic requirements are captured in a word-processor spec-
once up front and deployed over multiple ECUs in multiple vehicle ification document. This authoring process requires a great deal of
programs that share common high-level diagnostic requirements. time and effort and produces a document which is difficult to verify
The ECU-specific parts are not reusable across different ECUs in a as either complete or correct.
vehicle. This ECU-specific software will not fit the write-once-use- Once this document is completed, it is delivered to the supplier.
many model of the ECU independent software, but it can still be The supplier engineers must read and interpret the document. Less
done in a more efficient way through a source code generation pro- experienced suppliers will not fully understand the requirements
cess that automates as much of the ECU-specific software as on their own and will require significant support from the OEM
possible. in getting up the learning curve. Opportunities for misinterpreta-

3/16

23 Press Book_Seite_3-16_3-19.indd 2 09.02.2010 13:26:52 Uhr


tion are everywhere and almost always lead to non-compliant In addition, suppliers must also deal with the possibility of
implementations. In this situation, not only non-compliant imple- changes in diagnostic requirements from the OEM. These new docu-
mentations are likely, but also come in the form of multiple suppli- ments not only mean reworks, but also further increase the oppor-
ers having the same misunderstandings and producing the same tunity for misinterpretation of requirements that can lead to
issues across multiple ECUs. reworks of the reworks.
Once the ECU software is implemented and delivered to the OEM,
the OEM must test each ECU for compliance to requirements. Given Diagnostic source code generator
the process, the OEM has no choice other than to test each and
every requirement on each and every ECU. This means redundant From office productivity software to web applications, most mod-
and parallel testing of all ECUs. These tests are likely to identify ern software packages profit from including pre-built components.
failures that are shared by multiple ECUs. In the end, many engi- This enables the engineer to focus on the core tasks of the specific
neers are all working to find and resolve similar issues across multi- application and to reduce the overall complexity. This also appeals
ple ECUs. to the project manager as the development proceeds faster and
Frequently, diagnostic functions are the last implemented in an risks are reduced. The diagnostic component approach has another
ECU. Without diagnostics, many basic ECU functional requirements significant advantage. Different diagnostic specifications from dif-
are difficult or impossible to test. As a result, the late availability ferent OEMs can share a common application-programming inter-
of diagnostics forces many tests to wait until the last minute, even face. This interface not only hides the complexity of the extensive
for functional requirements implemented early in the development ECU-independent diagnostic specifications from the programmer,
cycle. Postponing important testing dramatically increases the risk but also keeps ECU application software design OEM-independent.
of identifying significant issues very late in the development cycle The OEM defines ECU-specific requirements as input data to the
and putting program timing at risk. source code generator. These formal requirements replace the cur-
Development engineers are left to learn and apply requirements rent word-processing based documents used today as a basis for
spanning numerous documents, from different organizations and software development. The source code generator creates an ECU-
different authors; each with their own points of view, sets of termi- specific diagnostic software component according to the OEM’s
nology and levels of completeness. Incomplete definitions, ambig- diagnostic requirements. Next, the supplier develops the ECU-spe-
uous wording, inconsistent terminology and requirements that are cific parts of the diagnostic software. The complexity of the diag-
just plain assumed and not specified make the job nearly impossi- nostic protocol is hidden by the application-programming interface
ble to execute right the first time. that connects the communication to the diagnostic functions in the
ECU.

Figure 2:
Figure 1: The diagnostic development process with the Vector
Conventional diagnostic development process with CANdela approach. Diagnostic data is stored in one
breaks in the data flow. The late implementation database and then reused in all subsequent process
results in a short integration and test phase. steps.

3/17

23 Press Book_Seite_3-16_3-19.indd 3 09.02.2010 13:26:53 Uhr


Advantages from the OEM perspectives The diagnostic component is typically available at the beginning of
the project. Because the component’s interface mirrors the function-
The component developer manually develops a framework that cov- al requirements, any ECU-specific requirements are insulated from
ers all ECU-independent requirements. This is the same process OEM specifications. This means that ECU-specific source code can be
done today by any supplier and the OEM. The main difference is reused for other vehicle programs with other OEMs without signifi-
that parallel and redundant efforts for implementation and testing cant modifications. This structure produces ECU application code that
are eliminated. Redundant implementation errors are simply avoided. is highly portable and not tied to a specific vehicle program.
This also eliminates common and parallel misunderstandings of the
diagnostic specifications. When the work is done and the compo- Solution – the CANdela approach with CANdesc
nent is ready for use, the same framework is shared by all suppliers.
The OEM must define ECU-specific requirements as input to the There is already a working implementation of this approach to imple-
source code generator. This formal specification of requirements menting diagnostics in an ECU. CANdesc, a part of the Vector CANdela
can be used for much more than just tailoring embedded software product family, implements exactly this approach (Figure 2).
components. It can be reused to generate a word-processor specifi- CANdesc works with FNOS, GMLAN, FIATLAN. and many more OEM
cation document and to generate input data to test systems. If an specifications CANdesc is applied in many ECUs in many real-world
appropriate tool supports the data entry process, the entire diag- vehicles.
nostic process will be more efficient than it is today. CANdelaStudio is the authoring tool to define the ECU-specific
Another advantage of software components is their availability. data. A use-case-oriented user interface provides an intuitive view
As the software component is typically ready for use at the begin- on diagnostic information and allows easy and comfortable edit-
ning of product development, the very first implementation of the ing. The CANdelaStudio data model covers all requirements neces-
ECU already contains diagnostics. This improves the quality of the sary for effective source code generation as described in this docu-
complete diagnostic implementation as late changes are reduced ment (Figure 3).
or avoided completely. The source code generation tool outputs the ECU diagnostic soft-
ware component source code (Figure 4).
Advantages from the supplier perspective Resource requirements are a very sensitive point in automotive
embedded software. CANdesc was designed with this point in mind.
The supplier generates source code for all OEM-specific require- Exact resource consumption depends on microcontroller and com-
ments. He does not need to interpret the OEM’s diagnostic protocol piler selection and so does the optimal generation configuration,
specification at all. Inconsistent interpretations and implementa- but typical values according to real-world experiences are shown
tions of the protocol are left out of the process, which leads to a here. Please note that these numbers represent a replacement for
significant reduction of development iterations. the resources consumed in a typical diagnostic implementation,
not an addition to them.

Figure 3:
Generation of an ECU diagnostic
software component

3/18

23 Press Book_Seite_3-16_3-19.indd 4 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 The Vector CANdela approach shows that the concept of comput-
control or transmission unit), about 5 k for even the smallest er generated diagnostic software components not only works in
ECUs real world applications, but also delivers on the promises made by
> RAM: about 128 bytes 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 implementa-
tion before the first bench delivery. The total diagnostic develop-
ment time is reduced by up to 80 %, which corresponds to a savings
in effort of about 4 man months (Figure 5).

Conclusion
Christoph Rätz
Dipl-Ing. Christoph Rätz (BA) studied
Diagnostic implementation is a significant part of the ECU develop- Computer Engineering at the University of
ment process. There are opportunities for significant gains in both Cooperative Education at Stuttgart. He is
the global product line manager for the
efficiency and quality. The malfunction detection strategies and Vehicle Diagnostics at Vector Informatik in
operational diagnostics strongly depend on an individual ECU – Stuttgart/Germany.
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, docu-
mentation and tester data replace their hand-made counterparts of
the conventional diagnostic development process.

Figure 4: Figure 5:
From diagnostic specification to C-Code Effort savings with the CANdela approach

3/19

23 Press Book_Seite_3-16_3-19.indd 5 09.02.2010 13:26:54 Uhr


24 Press Book_Seite_3-20_3-23:Press Report 4 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
world’s first ‘dry system’ dual-clutch
transmission represented a special chal-
lenge for the ECU’s 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 Until now, dual-clutch transmissions were only available in wet
transmission with the cost advantages of manual transmissions. In technology, i.e. with components running in oil. Although they of -
conjunction with ECM (Electronic Clutch Management), dual clutch fer the advantage of greater power loss absorption by oil cooling,
transmissions form the basis for modern drive concepts. While the this is contrasted by the disadvantages of a lower friction factor
ECM system handles electric motor actuation of the dual clutch, and a larger drag torque when idling. Since LuK uses electric mo-
transmission control ensures that two gears are always engaged si- tors to actuate the dry dual clutch, this of fers even greater poten-
multaneously. Usually gears 1, 3 and 5 are served by one transmis- tial for reducing fuel consumption and CO2 emissions.
sion 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 hun-
dredths of a second to shift gears and of fers better fuel economy
than manual shifting.

Greatest Ef ficiency with Dry Dual Clutch


The first ‘dry’ dual clutch was developed at the facilities of automo-
tive supplier LuK in Bühl (Figure 1). This company, part of the Scha-
ef fler Group and a specialist in clutch and transmission component
solutions, has contributed to the advancement of automotive tech-
nology 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) compo- Figure 1:
nents for torques greater than 300 Nm and the world’s first electro- The core of the modern dual-clutch transmission: Dry
mechanical automatic transmission. Meanwhile, every fourth car in (left) or wet (right) dual clutches ensure gear shifts
the world is driven with a LuK clutch. Today, the focus of the com- without inter ruption of tractive force. Software devel-
pany’s development is on alternative drive concepts too, such as opment for these drive concepts by LuK required fre-
components for dual-clutch transmissions and hybrid drives. quent flashing.

3/20
24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 2

Intelligent Software protects the Clutch System From in-house Flash Tool Development to universal Flash
A problem specif ic to the dry clutch becomes apparent when stop- Solution
ping on a hill, when the driver applies the braking torque via the At first, LuK handled the flashing that is frequently needed in soft-
gas pedal and clutch instead of the brakes. Due to poorer cooling, ware development (updating of program code or data in the ECUs)
the clutch gets hot much quicker than in a wet system. To protect with an in-house development that was even used to flash produc-
against premature wear and failure, intelligent driver warning tion ECUs. Independently, the clutch specialist conducted a search
strategies are required, which support the driver in optimally utiliz- for a diagnostic tool for CAN. After finding, dur ing a test phase,
ing the clutch. The software might achieve this, for example, by al- that other products were lacking in var ious areas – ranging from
lowing the vehicle to slowly roll free after a short period of time, the graphic user inter face to product support – LuK decided on
which induces the driver to automatically step on the brake pedal. CANdito from the Stuttgart-based company Vector Informatik. Vec-
Dur ing the drive, the electronics must adjust the clutch engage- tor impressed them with a solution that can implement all of the
ment to be quicker or slower depending on vehicle speed, gas pedal var ious flash methods and can also serve as a full diagnostic tester
position, etc. (Figure 2).

Overall, numerous constraints and parameters need to be consid- In the diagnostic tester CANdito, the LuK employees found precise-
ered in automatic clutch operation, and they change dynamically ly what they had been looking for, and more. The tool enables sym-
dur ing operation. The clutch heats up, cools down again and is the- bolic access to all data and functions that are accessible via the
refore continually changing its character istics. The electronics must diagnostic protocol. It reads in ODX-2.0 description files and sup-
continually adapt the behavior of the automatic dual clutch to the- ports scripts for automating diagnostic and operating sequences.
se changing parameters. LuK utilizes an advanced computational ECU var iants are automatically detected. The author ing tool
model that yields a clutch mechanical design that is less complex CANdelaStudio is used to describe the diagnostic data in CDD and
and is therefore more economical for the automotive OEM. ODX formats. Each ECU is described in a separate document that is
based on a document template. A var iants concept makes it possi-
ble to define the commonalities and dif ferences of an ECU’s var i-
ants, largely without redundancies. Full parameter ization simply

Figure 2:
By using the right tool
and ODX, a smooth tran-
sition of flash processes
is possible – from devel-
opment to production.

3/21
24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 3

involves reading in the ECU description file. All communication pa- whether an update is even necessary. Scripts ensure that the tool
rameters and all existing services and data are immediately availa- always uses the right software for the par ticular hardware var iant,
ble. In a separate work step, the embedded software can also be even when the same ECU hardware is used on numerous dif ferent
generated from the description file. This ensures that the diagnos- vehicle models. Use of CANdito as a diagnostic tester and flash tool
tic description, the software in the ECU and parameter ization of – including script functions to simplify the job – goes a long way
the diagnostic tester are always coordinated. 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 Current trends in reprogramming memory chips include: ODX-F, par-
out the software currently in the ECU before flashing. This is neces- allel flashing and flashing with increased bandwidth via FlexRay. In
sary to ensure that the correct software version is being flashed in light of these wide-ranging trends, questions related to protection
the relevant ECU. Fur thermore, this capability is impor tant for of investment and assurance of future coverage are thoroughly jus-
reading out system parameters and the error memory or for making tified. Users of Vector products benefit here, not only because they
before/after compar isons. In the old solution, the diagnostic tester represent a scalable tool chain with multiple flash solutions, but al-
was needed to access these data. After the user had read out the so because they of fer timely program versions that meet current
necessary data, the user would stop the tester, start the flash tool standards. While ODX-F support and parallel flashing are already
and select the appropriate files – an intricate procedure. available, FlexRay support is already coming with the next release.
A remedy to this situation was found in use of the script language Existing author ing tools for the development of diagnostic parame-
integrated in CANdito (Figure 3). After communication has been es- ter ization or the ODX-F flash containers round out this area.
tablished, the tool reads out the identification of the software cur-
rently in the ECU. Based on a table, the tool autonomously decides

Werner Schmitt
Electrical technician, works on developing
electronic systems in the transmission auto-
mation area at LuK GmbH & Co. oHG. He is
responsible for diagnostics as well as start-
up and service of these systems.

Andreas Patzer
(Graduate engineer) works at Vector Infor-
matik GmbH where he is Business Develop-
ment Manager in the “Measurement and Cali-
bration” product line.
Figure 3:
LuK develops flash jobs using the script editor inte-
grated 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
24 Press Book_Seite_3-20_3-23:Press Report 4 09.02.2010 13:14 Uhr Seite 4

3/23
25 Press Book_Seite_3-24_3-27:Press Report 3 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 solu-
tions 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 fea-
tures, country code, serial number, safety aspects, etc. Figure 1:
Memory structure in ECU with FlashBootLoader
At a minimum, the following components are needed for flashing: from Vector.
> Flash data,
> Flash tool,
> Flash bootloader, which is integrated in the ECU and executes the The flash data contain the program code and specif ic parameter
actual erase/write processes sets intended for the ECU. The flash tool implements the flash rou-
> The necessary meta information. tine on the PC side. If the tool only supports a special flash routine,

3/24
25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 2

then dedicated flash tools may be needed for dif ferent flash jobs. CAN drivers, CCP/XCP protocols, etc. A generator tool is responsible
Data-driven, multipurpose flash tools are ef ficient and more mod- for data configuration and generation of the header files.
ern. 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 sin- If one utilizes a suitable author ing tool to conveniently generate
gle dedicated tool is all that is needed to manage flash jobs and as- diagnostic data and services, the tool can be used to directly pa-
sociated flash data in containers, and it always has the same user rameter ize the diagnostic tester and generate the relevant diag-
inter face. nostic code for the ECU. An ODX-D data container stores the diag-
nostic data and flash job together. There is an ODX-F management
Responsible for the routine on the ECU side is the flash bootloader and author ing tool for linking flash data, jobs and meta-data. The
(FBL) that is integrated in the ECU and is always active. The FBL is associated communication parameters are not contained in the
par titioned into the permanent bootloader existing in the ECU and ODX-D container, rather in a dedicated ODX-C container ('C' stands
the flash driver. For security reasons, the flash driver is only tem- for “Communication”), Figure 2.
porarily loaded in the ECU’s RAM, since among other things it con-
tains 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 diag-
nostic layer and thereby ensures that the ECU always remains ad-
dressable, even if the flash process could not be completed properly.

Process-oriented flashing
A special challenge in flashing is to always load the right applica-
tion in an ECU. That is the only way to ensure complete and error-
free 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 to-
gether 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 informa-
tion 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 pro-
duction. So ECU developers sometimes flash – not via the diagnos-
tic protocol, but via CCP (CAN Calibration Protocol) or XCP (Univer-
sal Measurement and Calibration Protocol).

Rational generation and management by tools


To generate the executable flashable binary files via compiler/link- Figure 2:
er, one needs the source code for the application, diagnostic code Based on the ODX-F container, the flash routine is
and embedded code elements, which are supplemented by check- executed fully automatically with CANape, CANdito
sum information, fingerprints and other data. Use of a comprehen- and CANditoFlash. The container contains all necessary
sive product solution quickly leads to the desired results – e.g. one data and infor mation such as reference to the flash
from Vector Informatik with source code for the embedded por tion file, flash job and meta infor mation.
in the ECU, consisting of operating system, network management,

3/25
25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 3

Figure 3:
Use of the ODX-Standards enables a
smooth transition in flash process-
es from development to production.

Getting “a grip” on references the user by of fer ing enhanced flexibility with the goal of cover ing a
Later in the flash process the system reads from the ODX-F file the wide variety of requirements and job tasks related to flashing.
flash files, meta information and reference to the flash job being Flash routines cannot be implemented without suitable tool chains.
used. The latter is found in the diagnostic description, from which From Vector the ECU developer gets universal tool support in all
it is loaded and executed. References are used to produce the rela- aspects of flashing: CANdelaStudio for specifying diagnostic
tionships between the ODX-F, ODX-D and ODX-C containers. requirements and generating the CDD, ODX-D and ODX-C files,
CANdelaFlash for generating the ODX-F flash containers and the
On the one hand, references to flash data and flash jobs are easy to flash bootloader for a wide range of controllers. As author ing and
replace without requir ing regeneration of the ODX files, but they development tools, CANape and CANdito are used to generate
are also associated with the risk that the process will no longer script-based flash routines, and they also form the actual runtime
function if a referenced document is missing. One solution to this environment for the flash process. CANditoFlash serves as a pure
problem was to create “meta” containers that save all associated runtime environment for flash processes generated with CANape
data in a single, compressed file. By def inition, the containers – and CANdito.
with the 'PDX' (Packaged ODX) extension – do not permit any refer-
ences 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 rou- Andreas Patzer
tine. Fur thermore, it permits both fully-automatic and semi-auto- (Graduate engineer) is employed at Vector
matic flashing. Fully automatic means that the user does not per - Informatik GmbH as Business Development
Manager for the “Measurement and Calibra-
form any configuration or selection activities. In semi-automatic
tion” product line.
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 de-
velopment phase (Figure 3). Gener ic and data-driven tools benefit

3/26
25 Press Book_Seite_3-24_3-27:Press Report 3 09.02.2010 13:14 Uhr Seite 4

Vehicle
Diagnostics

ODX at the press of a button! Rely on


proved and tested ODX solutions
Distr. Systems
In your ODX development, you can benefit from the know-how
Development

of our employees and our comprehensive experience acquired


in production projects and ODX standards committee work. Take
Test
advantage of Vector’s universal ODX products and services:
ECU

> Create diagnostic data easily and exchange this data with
your process partners
Diagnostics
> Diagnose individual ECUs or the total vehicle
> Flash ECUs based on ODX-F data
> Migrate master data to ODX
Calibration
> Benefit from our consultation in implementing and
ECU

integrating ODX
o
Indig
Software Add ODX to your diagnostic development reliably and quickly. New: gnost
ics
ia
ECU

Vector tools and services will support you in all phases. ic le d


ve h X
Easy on OD
based
Management
Press the button! www.odx-solutions.com
Process

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. +49 711 8 06 70-0
www.vector.com
26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 1

Flash programming via CAN


Tool

requires supplier’s flexibility


By Peter Liebscher (Vector Informatik)

A lot of flexibility is de-


manded of automotive
suppliers in the develop-
ment of electronic compo-
nents. This also applies to
the area of Flash program-
ming. Constraints in the
various phases of the prod-
uct 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 avail-
able to them.
ECUs need to be re-
programmed and analyzed
more or less frequently over
the various phases of a ve-
hicle ranging from develop-
ment to production to op-
eration in the target vehicle
to diagnostic analysis of re-
turned product. Once the
ECU has been installed in sioned at the end of the pro- indirect path to manipulate a hard-coded Flash proce-
the vehicle, CAN is the only duction process, so that in or spy data. dure is still employed, but
means of accessing it. In the normal operation only the A specific application the future belongs to flexible
development phase too the FXVWRPHU·V )ODVKORDGHU LV at Continental involves re- standard tools with which
CAN bus is utilized as an in- still active. For the suppli- programming a multiproces- the numerous challenges
terface for exchanging soft- er this eliminates potential sor system with master and of the Flash process can be
ware. For suppliers the ba- compatibility problems be- slave controllers and ex- managed much more ratio-
sic challenge is to achieve tween the production boot- ternal sensors. The master nally at the supplier. The ad-
the most rational flow in ORDGHU DQG WKH FXVWRPHU·V controller can be flashed di- vantage of parameterization
their own development and flashing process. rectly by CAN; however the using tools such as CANape
production phases and sat- Since the topic of secu- slave and sensors can only and CANdito from Vector is
isfy the (strict) requirements rity plays an important role be addressed indirectly in that all information relevant
of the vehicle OEM. in Flash programming in the flashing. To gain control over to the Flash process can be
The solution approach vehicle operation phase, all the entire Flash process saved in standardized flash
of the company Continental security mechanisms for in- given the described con- data containers. Use of the
Automotive Systems (www. tegrity, authenticity, copy straints, the Stuttgart-based ODX Flash format as a fu-
conti-online.com), for exam- protection, etc. come into company Vector Informatik, ture de-facto standard en-
ple, involves creating their play here. These aspects a specialist in developing ables data exchange with
own OEM-specific Flash- are gaining in importance, automotive electronics, was other tools. At the same time
loader for development and because Continental has hired to implement a special required diagnostic data are
production phases and a the capability of reactivating extension. This extension is stored in the container that
customer-specific Flash- the production boot-loader capable of utilizing the seri- might be generated with the
loader for the product oper- to analyze returned prod- al IPC (Interprocessor Com- CANdelaStudio program of
ation phase. The production uct. Therefore, in reactiva- munication) connection be- the same producer.
boot-loader is optimized for tion precautions are taken tween the master and slave
standardized in-house flash to ensure that unauthorized in Flash programming. In peter.liebscher@vector-in-
processes and is decomis- persons cannot exploit this this project a Flash tool with formatik.de

3/28 22 Source: CAN Newsletter, CAN in Automation


26 Press Book_Seite_3-28_3-29:Press Report 2 09.02.2010 13:04 Uhr Seite 2

3/29
27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 1

1 l AUTOMOTIVE 9. 2 0 0 6
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 per- 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


forms computations to acquire data on vehicle speed, wo rke d t o g e t h e r w i t h B M W o n t h e
steering angle, longitudinal and lateral acceleration,
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 -
body and wheel accelerations as well as their heights.
The swivel motors of the stabilizer bars and electro- 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
magnetic valves of the shock absorbers are controlled 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 -
based on this information.This provides full-time con-
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
trol of body roll and damping based on the given dri-
ving situation.The new BMW X5 is the first vehicle in 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
the world to utilize FlexRay technology. H A N S E R a u t o m o t i ve .

Mr. Peteratzinger, why FlexRay and why now? Why did BMW chose suspension control as a pilot
Peteratzinger: That was a strategic decision. We have alre- application?
ady reached the limits of reasonable bus loads with CAN, Peteratzinger FlexRay is a completely new development,
and would otherwise need to install multiple CAN buses, and we had no knowledge base from other production pro-
and not just for high-end products. Our analyses indicated jects. In this case, the first step was to build up this know-
that up to eight CAN buses would be needed for just the ledge. It was therefore important for BMW to be able to quik-
powertrain and chassis areas in the next 7-series car. But kly apply this acquired knowledge and implement necessa-
we do not want to implement even more sub-buses; at ry changes during development. In a system such as an engi-
some point they become unmanageable. Therefore, some ne controller the adaptation effort would be considerable due
years ago BMW decided to build up its development expe- to the large number of interfaces. This new suspension
rience with FlexRay. We now have a foundation for future system has a well-defined and limited functionality. In a small
electrical systems and will expand them to include additio- team, together with our ECU suppliers and development
nal vehicle systems in upcoming car models. If we did not partners such as Vector, we were
start on this now, we would have had to utilize a large num- able to make decisions and intro-
ber of CAN systems and sub-buses to carry us through, and duce modifications over short
this would last for many years due to the development decision-making paths. Further-
cycles for car models. more, aspects of this application
made it possible to implement
Steiner: Another criterion of course is transmission rate. In many new FlexRay features
the current application sensor signals are acquired and pro- meaningfully.
cessed both by the central ECU and by the satellites. On
the one hand, this decentralized approach leads to an incre- When did you decide to elimi-
ased demand for communication, and on the other hand nate CAN entirely as a fall-back
shorter cycle times are needed on this and future architec- solution in this project?
tures due to their separation of sensors, control system and Peteratzinger: That was done in a
actuator. In addition, many of the new functions and archi- relatively early phase of the pro-
tectures place stricter requirements on real-time capability ject in the summer of 2004. After Martin Peteratzinger, Graduate
and communication availability. This can only succeed with we had successfully started up Engineer (University of Applied
a bus system like FlexRay. FlexRay as a bus system to net- Sciences), develops electronics
work the five ECUs in a stable in the vehicle dynamics area of
manner and had all identified and the BMW Group and has func-
Translated by Vector Informatik assessed unresolved risk issues, tional responsibility for the
FlexRay application.
4/0
27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 2

INTERVIEW l AUTOMOTIVE 9. 2 0 0 6 l2

VECTOR'S CANAPE basic definitions. Part 2 of the document des-


cribes the XCP command set as a bus-indepen-
dent protocol layer. Whenever a new Transport
Layer is added, as is being done now with Flex-
Ray, 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 spe-
cification defines dynamic bandwidth control.
Since the XCP protocol is essentially a Master-
Slave communication protocol, the XCP Master
can distribute XCP Slots to individual Slaves
depending on how much bandwidth the Slave
needs. Dynamic bandwidth management requi-
res that the Master knows which slots are avai-
lable for this purpose. That must be a part of the
FIBEX file.

Optimization of ECU parameters with CANape Why is that good?


Steiner: Compared to the potential bandwidth
of FlexRay the current bus load is still very small.
the decision was made to eliminate CAN altogether begin- We therefore had the luxury of making three XCP slots avai-
ning with the next hardware level. In the process this rai- lable to each ECU: One to communicate from
sed the question: How would we calibrate the application? CANape in the direction of the ECU, and two to
Initially calibration was still performed via CAN, but in the send measurement data from the ECU in the
end this fall-back level was dropped. Therefore we first direction of CANape. That means that 15 slots
developed a CCP-CAN-FlexRay gateway that converts CCP are used just for XCP. In the next car models the
messages to FlexRay and in the reverse direction too. In bus will be utilized more intensively with more
the ECUs we also “restructured” the CCP module for Flex- ECUs. Then we will no lon-
Ray. This made it easier to continue utilizing CANape with ger have this freedom. All Florian Steiner,
CCP (CAN Calibration Protocol). But that too was just a tran- ECUs must then share one Graduate Engi-
sitional solution, since first it is necessary to create such slot or just a few slots for neer (University
gateways, and then they need to be maintained for a num- XCP. of Applied Scien-
ber of years. Therefore it was important to find a product The only limitation here is ces), develops
that would not just work exclusively in one project, but that it will no longer be pos- electronics in the
would be available to the entire market. In the ASAM wor- sible to calibrate all ECUs vehicle dynamics
king committee XCP on FlexRay was driven by Vector with simultaneously. However, area of the BMW
the support of BMW and attained specification status in this is of no consequence in Group and as a FlexRay deve-
February 2006. practice, because devel- lopment expert he is respon-
opers generally only calibrate sible for production-level ECU
Schuermans: Technically we had gotten a handle on the their “own” ECU. With dyna- development.
“measurement & calibration via XCP on FlexRay” concept mic bandwidth allocation this
relatively quickly. For Vector though it was clear that we had can be done very quickly.
to turn XCP on FlexRay into a standard as quickly as possi-
ble. ASAM has been working on XCP for quite a long time That is XCP will remain in the ECU?
now. XCP itself was finalized in 2003. The aim of the stan- Steiner: Yes! Although there is no need for direct measu-
dard is to only require adaptation of the underlying trans- rement on the FlexRay bus while it is in service, the XCP
port protocol. The specific solution needs at BMW allowed module will be retained in production versions of the ECU.
us to implement both the XCP stack in the ECU and on the Diagnostics of the FlexRay ECUs is performed via OBD, the
tool side CANape as the XCP Master very quickly. standard diagnostic interface in the vehicle. XCP plays a
central role in testing and validating ECU functions and is
XCP on FlexRay was standardized in February. What therefore a component of the production software.
was involved in this process?
Schuermans: Of course the work in ASAM requires a cer- Doesn’t that pose a risk? Certainly there are people
tain amount of time: First a project application is submitted, who might want to reprogram the chassis.
then a working committee is formed, and finally a draft is Schuermans: XCP, and I am not just referring to XCP on
developed. XCP is split up into several subdocuments. Part FlexRay here, has a so-called Seed&Key security mecha-
1 is an overview of the protocol family, XCP features and nism. XCP is of course based on a Master-Slave principle.

4/1
27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 3

3 l AUTOMOTIVE 9. 2 0 0 6
INTERVIEW
The Master must ask the Slave for a "Seed", Roel Schuermans, Graduate Engineer, is
and this is used to compute an associated Senior Product Management Engineer at
key. The Master does not grant the Slave Vector Informatik for the “Measurement &
access until the correct key is obtained. Calibration” product line. As an expert in
the FlexRay protocol he has been involved
Peteratzinger: Our hardware supplier has in the development of XCP on FlexRay in
also installed another software protection the ASAM working committee up to its
mechanism. So protection is twofold. standardization and worked on its imple-
mentation 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 sup- issues. During HANSER automotive’s FlexRay roduct Day
pliers for a solution. In this context there were many open in 2004 we met with experts from Vector, discussed these
issues and formulated our requirements. Although no stan-
dard 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 stan-
dard in the ASAM working committee. It was also a good fit,
because Vector’s 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 assess-


ment 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

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.

4/2
27 Press Book_Seite_4-00_4-03:Press Report 2 09.02.2010 13:17 Uhr Seite 4

ECU
Calibration

:PVSFGæDJFOUBMMSPVOETPMVUJPOGPSNFB
TVSFNFOU DBMJCSBUJPOBOEEJBHOPTUJDT
Universal tool support simplifies your calibration of ECUs. The
versatile CANape tool lets you cover all application cases effort-
lessly:

Distr. Systems
> Quickly and reliably capture measured data from various
Development

sources – synchronous and time-precise. Whether via CCP,


XCP-on-CAN/FlexRay/Ethernet or from external test
equipment
ECU

> Conveniently calibrate the parameters of your ECU algo-


rithms, either online in the ECU or offline in the Hex file
Diagnostics
> 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
Calibration
diagnostic services and flash solutions
ECU

> Benefit from a universal tool chain with extensive rapid


prototyping capabilities and MATLAB/Simulink integration
Software
ECU

Vector supports you from functional development to produc-


tion-ready ECU, in the laboratory, on the test bench and du-
Management
ring driving trials.
Process

Information and downloads: www.ecu-calibration.com

Vector Informatik GmbH


Ingersheimer Str. 24
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 Audi’s 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 Audi’s 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 communi- program, parameter values such as characteristic maps, curves and
cation bus on its next generation of sporty luxury limousines. Since values need to be recorded and optimized in measurements made
FlexRay – compared to CAN – offers a significantly greater band- on the test bench and in driving trials. Audi engineers tune their
width of 10 MBit/s. Many electronic chassis and driver assistance chassis and assistance systems in the framework of ECU calibration,
systems are connected to this deterministic and time-triggered bus and they then load the parameter set files into the ECUs’ applica-
system. For Audi developers, this decision meant that several thou- tion memory.
sand parameters needed to be directly parameterized via an To calibrate ECUs centrally from a single master and via a uniform
AUTOSAR FlexRay stack. Compared to CAN, more than twice as many interface – over the entire course of development – a standardized
measured values can be acquired simultaneously using XCP-on- measurement and calibration protocol is necessary. In 2003, ASAM
FlexRay. Furthermore, it is possible to transmit large quantities of (Association for Standardization of Automation and Measuring Sys-
data with a higher throughput. tems) defined the universal measurement and calibration protocol,
XCP, to serve this purpose. It is a logical advancement of CCP (CAN
XCP on FlexRay Calibration Protocol) [1]. Communication via XCP is executed by the
Master-Slave principle. An XCP software module integrated in each
A laboratory model by itself is of limited use in determining the ECU serves as a slave. The greatest advantage of the XCP protocol is
parameters of a control algorithm. Although the algorithms of the that it offers separation of the transport and protocol layers. The
functions are permanently stored in the ECU-specific software protocol layer is the same on all bus systems, regardless of whether

4/4

28 Press Book_Seite_4-04_4-09.indd 2 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 transport layer software modules for the slaves using XCP-on-
officially released Version 1.0 of the Transport Layer specification FlexRay from a single supplier.
for “XCP on FlexRay”.
On earlier CAN projects, the Audi development team had already XCP integration in the AUTOSAR model
worked with XCP and CANape, the all-round tool from Vector for ECU
measurement, calibration and diagnostics (Figure 1). CANape has Audi integrated the XCP software modules in the ECUs of various
supported an XCP-on-FlexRay interface since 2005. Audi decided to suppliers. Even after the ECUs calibration is over, the XCP software
source both the XCP master (CANape) and the protocol and modules shall remain available. This makes efficient memory

Figure 2:
Integration of
Vector XCP soft-
ware modules in
an AUTOSAR 3.0
compatible
application.

4/5

28 Press Book_Seite_4-04_4-09.indd 3 09.02.2010 13:25:47 Uhr


utilization and minimal execution time essential. In addition, the form of a PCI header (Protocol Control Information), thereby form-
XCP software modules have to be AUTOSAR-compatible. Vector ing an L-PDU (Data Link Layer PDU), which in turn is routed to the
implemented this requirement on the XCP transport layer such that “FlexRay driver”. That is how each participating software module
it is placed above the AUTOSAR communication stack (FlexRay or completes data received with module-specific information, making
CAN) using the PDU router (Figure 2). In the integration phase, it possible to reconstruct the data at the receiver. At the end of the
the two XCP software modules are configured with the help of the chain, the FlexRay controller transmits the XCP data as a frame
GENy configuration tool and a network description file in FIBEX within a FlexRay slot (time window). Per the XCP specification these
format. frames must exclusively contain XCP data. Therefore, in the cross-
system FIBEX network description file, some slots in the FlexRay
Dynamic management of FlexRay bandwidth schedule are exclusively to be reserved for XCP-PDUs and cannot
not be combined with PDUs issued from the application.
Since AUTOSAR compatibility is required for the XCP-on-FlexRay For the control commands (CTOs), two individual XCP slots are
software modules, this means that the PC-supported master must sufficient for all ECUs thanks to the slave-referenced node address
perform special tasks. During ECU calibration, the XCP master and (node address for XCP: NAX). The exact number of DTOs needed for
slaves exchange FlexRay messages. These frames contain either the measured data or stimuli data depends on the specific mea-
Command Transfer Objects (CTO) with control commands or Data surement being executed and may vary widely over the course of a
Transfer Objects (DTO) with measured or stimuli data. When such an calibration. So the need for XCP slots also varies for each ECU.
XCP object is transmitted to the master (Figure 3), the “XCP trans- To ensure that Audi engineers can efficiently transmit XCP data
port layer” transfers the data to the PDU router and thereby to the from multiple ECUs with a limited number of available XCP slots, it
“FlexRay interface”. is necessary to dynamically allocate the available bandwidth at
Because of the requirement for AUTOSAR compatibility, this runtime to all participating ECUs. However, AUTOSAR does not allow
transfer must be made in the form of an AUTOSAR-conformant PDU reconfiguration of the “FlexRay driver” at runtime. Therefore, in
(Protocol Data Unit). Since the PDU originates from the XCP mod- the integration phase the “FlexRay drivers” are configured so that
ule, it is called the XCP-PDU. The FlexRay interface completes the all XCP slots are allocated to all of the ECUs. At the same time, the
received XCP-PDU by adding its own specific information in 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

28 Press Book_Seite_4-04_4-09.indd 4 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 payload, offers XCP frames that are many times longer than those
unique XCP slot in the FlexRay schedule is available for each indi- of CAN (8 bytes). The “Short Download” function simultaneously
vidual XCP buffer. To attain the necessary flexibility over all ECUs, encodes the address and contents in a single L-PDU, so that memo-
the XCP transport layer command “FLX_ASSIGN” is used to modify – ry areas can be exchanged between the master and slave much
on the XCP level – the allocation of XCP buffers to the different more quickly than with CAN.
L-PDUs (or FlexRay slots) before each measurement (Figure 4). Furthermore, XCP enables oversampling, which is independent
What is important here is to configure all participating ECUs with of the FlexRay cycle, in order to measure very dynamic signals
the maximum available XCP slots, during software integration. This (Figure 5). CANape uses the so-called “In cycle multiple DAQ list
results in the identical allocation of XCP slots on each ECU. Before transmission” to acquire measured signals of a predefined DAQ list
each measurement, only those XCP buffers that are actually needed and their time stamps multiple times per FlexRay base cycle (gener-
are selected. A central “dynamic bandwidth management” ensures ally 5 ms long).
unique ECU slot allocations for XCP among all slaves. CANape han- To significantly accelerate the start procedure before each mea-
dles this task with the help of the ECU-specific A2L description files surement, the necessary initialization also had to be optimized
that provide information about the internal ECU buffers. thanks to the extension of the previous single “WRITE-DAQ” com-
mand. The new command “WRITE-DAQ-MULTIPLE” from the not yet
XCP use is optimized thanks to FlexRay 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 cali-
bration at Audi. In three additional functions, Vector specifically
exploits the fact that FlexRay, with it’s up to 254 bytes of data

Figure 4:
Before each measurement, the XCP
objects are dynamically configured
in the dynamic segment.

4/7

28 Press Book_Seite_4-04_4-09.indd 5 09.02.2010 13:25:48 Uhr


Summary
Christian Braun, Audi
studied Electrical Engineering at the Techni-
Audi engineers rely on the MCD tool CANape to develop new models cal College of Munich, specializing in Data
in the context of test trials and calibration drives, in order to mea- Technology. After graduating in 1996, he
joined Audi AG where he was responsible for
sure and calibrate internal ECU parameters with XCP-on-FlexRay. electronic development of various ESP
Vector has extended its CANape and XCP software modules for this systems. Since 2006, he has been working in
purpose. Besides extending the XCP software modules for AUTOSAR the area of Chassis Electronics Development
at Audi where he is responsible for measure-
compatibility, a major task was to implement dynamic bandwidth
ment tools and system networking.
management for FlexRay. Choosing Vector as software supplier and
development partner was easy for Audi, since both the XCP soft-
ware modules for the slaves and the XCP master, CANape, come Pascale Morizur, Vector
studied Physics-Electronics at the Grande
from a single source – Vector – and are perfectly tuned to one École ICPI in Lyon (France). After graduating
another. All extensions can be obtained for the current version of in 1986, she worked for 10 years at MAN
CANape and the XCP-on-FlexRay software modules. Commercial Vehicles in advanced develop-
ment for the area of CAN, J1939 and Diagno-
stics. Since 2005, she has been employed as
a product management engineer at Vector
Translation of a German publication in Informatik GmbH in the area of Embedded
Hanser Automotive, 7-8/2008 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 transmis-
sion” to measure
very dynamic
signals from a DAQ
list. The signal is
measured several
times per FlexRay
base cycle.

4/8

28 Press Book_Seite_4-04_4-09.indd 6 09.02.2010 13:25:48 Uhr


4/9

28 Press Book_Seite_4-04_4-09.indd 7 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 compen-
sate. 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 run-
time. 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 cross-OEM standard. However, additional bus systems such as
longer uncommon. Since numerous dynamic processes need to be FlexRay, LIN, MOST, etc. came into play with the continued devel-
controlled in a vehicle, the typical tasks of ECU calibration include opment of automotive electronics. Since CCP’s use was restricted to
optimization of control algorithms. CAN-networked applications, it increasingly encountered limita-
In the case of a PID controller, there are almost limitless possible tions in terms of its potential areas of use. This led to the develop-
variations in calibrating the proportional, integral and derivative ment of its successor, XCP.
components. Therefore, it usually takes some effort until a suffi-
ciently good compromise is found between stability, speed and Universal standardized protocol
transient behavior. This can be accomplished by reading and modi-
fying parameters during runtime (Figure 1). The “Universal Measurement and Calibration Protocol” (XCP), like
To keep the time and cost requirements for ECU calibration low, CCP, also has its origins in the Association for Standardization of
engineers and technicians depend on powerful tools and standards Automation and Measuring Systems (ASAM) [1] and was standard-
that enable flexible read and write access to variables or memory ized in the year 2003. The “X” stands for the variable and inter-
contents. For this purpose, the CAN Calibration Protocol (CCP) was changeable transport layer. XCP separates the protocol and trans-
created in the 1990s, a time in which CAN was the only dominant port layers completely by means of a two-layer protocol, and it
networking system in the automobile. CCP was slated to become a takes a Single-Master/Multi-Slave approach. Depending on the

4/10

29 Press Book_Seite_4-10_4-15.indd 2 09.02.2010 13:28:05 Uhr


transport layer in question, the protocol might be referred to as identifies the amount of bandwidth still available and dynamically
XCP-on-CAN, XCP-on-Ethernet, XCP-on-UART/SPI or XCP-on-LIN, for allocates it to the current application data traffic very efficiently.
example (Figure 2). The available bandwidth is thereby optimally exploited in XCP com-
A XCP Master is capable of communicating with different XCP Slaves munication and hardly affects normal FlexRay communication at all.
simultaneously. These include: Other options being considered for the future include XCP-on-
> ECUs or ECU prototypes LIN; also possible would be XCP-on-K-Line or XCP-on-MOST, if there
> Measurement and calibration hardware such as debugging is sufficient demand for them from user groups. The broad range of
interfaces or memory emulators supported transport layers enables simple migration from broad-
> Rapid prototyping hardware band solutions such as Ethernet or USB in the development phase
> HIL/SIL systems to a final CAN interface in series production.

To meet the challenge of serving as a universal communication Single-Master/Multi-Slave concept


solution for a large variety of applications, the ASAM Working
Group emphasized the following criteria in the design of XCP: Mini- The measurement and calibration system assumes the role of the
mal resource usage in the ECU for RAM, ROM and required runtime, XCP Master, while the ECU acts as a Slave. Master and Slave each
efficient communication, easy implementation of the XCP Slave, communicate via the XCP drivers integrated in them. For each Slave
plug-and-play capability with low configuration effort, small num- there is an ECU description file; information specified in this file
ber of parameters and scalability. includes: Allocations between (symbolic) variable names and their
address ranges, physical meanings of the data, and the checksum
Interchangeable transport layer method being used. The XCP Master can read out all of the informa-
tion it needs from these A2L description files.
XCP is capable of utilizing the same protocol layer on different In communication via XCP a distinction is made between the
transport layers. This protocol is a universal measurement and cali- “Command Transfer Object” (CTO) and the “Data Transfer Object”
bration protocol that operates independent of the network type (DTO). The Master might send a command via a Command Transfer
used. Currently, ASAM has defined these transport layers in stand- Object over the bus to the ECU that acknowledges it over the same
ards: XCP-on-CAN, XCP-on-SxI (SPI, SCI), XCP-on-Ethernet (TCP/IP path after executing the requested service. CTOs provided are: CMD
and UDP/IP), XCP-on-USB and XCP-on-FlexRay. The last named (Command), RES (Response), ERR (Error), EV (Event) and SERV
variant is the latest member of the protocol line-up, and it has (Service Request Processor). The DAQ (Data Acquisition) and STIM
been specified since early 2006. One special technical feature of (Stimulation) Data Transfer Objects are used for event-driven read-
XCP-on-FlexRay is its dynamic bandwidth control. A measurement, ing of measurement variables from memory, or for writing of values
calibration and diagnostic tool (MCD tool) such as CANape [2] 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

29 Press Book_Seite_4-10_4-15.indd 3 09.02.2010 13:28:06 Uhr


From automotive bus to standard PC interface megabyte-size data volumes with 32-bit processors over high-
speed networks such as Ethernet. Since an XCP driver is made up of
PC platforms are used almost exclusively as the Master for measure- mandatory and optional functions, driver size can be scaled to
ment and calibration tasks. For direct connections to automotive match the available ROM/Flash size. In the ECU, resource usage is
bus systems such as CAN, LIN, FlexRay, MOST or K-Line, the PC is characterized by whether the focus is on high data throughput or
generally equipped with one or more hardware interfaces. Further- on low processor load and RAM size. With regard to bus load, the
more, the XCP Master is capable of utilizing standard PC interfaces basic consideration is: Number of signal transmissions vs. bus
such as Ethernet, USB and RS232. Of course, in such solutions no bandwidth. Overall, the XCP drivers are easy to implement and
other costs are incurred for interface hardware. Measurement and require just a few parameters.
calibration systems with debugging interfaces (JTAG, TRACE, etc.)
and memory emulators can be implemented in this way. In princi- Event-driven periodic data acquisition
ple, the standard PC interfaces are also well-suited for connecting
gateways between different bus systems; FlexRay-on-Ethernet ECUs operate in discrete time intervals. The length of such a time
could handle this, for example. And finally, there are the conven- interval can be defined in a fixed way (e.g. 10 milliseconds) or the
tional analog and digital I/O channels that are utilized in many length of a time interval may be event-dependent (e.g. one engine
development and test layouts involving especially time-critical revolution). In the case of fixed defined time intervals, the end of
measurements. the time slice is marked by the expiration of a timer. Expressed in
A significant advantage in the use of XCP lies in the fact that a generalized terms, such expiration of a timer is also an event. The
single standardized protocol suffices for all of these applications. task of the ECU is to complete all computational and control tasks
Without XCP it would be necessary to implement a proprietary driv- within the specific time slice. To obtain correlated data from the
er for each communication channel. However, performance losses XCP Slave, the DAQ mechanism of the XCP protocol is now used. In
need to be taken into account when multiple drivers are used in this mechanism, the XCP-Master informs the Slave, before the
parallel. Moreover, the risk of undesirable interactions and insta- beginning of the measurement, which signals are to be measured
bilities increases. when certain events elapse. If the event now occurs (e.g. the 10
millisecond timer expires), the XCP Slave reads the previously
Versatile, scalable and resource-economizing defined data from the memory, copies them to a protected RAM
area and sends them to the Master in the form of messages. This
One and the same XCP driver code is used for all communication assures that the values originate from the same event cycle and
processes. It can serve to send just a few bytes that come from correlate.
small controllers and interfaces, e.g. 8-Bit processors with inte- The Master receives the data provided with a time stamp and saves
grated serial interface. Or the same code might be used to send 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

29 Press Book_Seite_4-10_4-15.indd 4 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 storage schemes for characteristic maps, and much more. High-
hardware being used, e.g. CANcardXL. In the measurement file, all performance calibration tools such as CANape from the Vector dis-
data are synchronized in reference to the Master time base and are play the characteristic curves and maps clearly on the screen in
then further processed, e.g. by visualizing the measurement values graphic diagrams or as numeric values in tables.
on a global time axis. This allows multiple data channels of different
XCP Slaves to be displayed consistently in one diagram. Rapid prototyping with CANape and XCP
Besides the advantages of XCP compared to CCP already been
mentioned, XCP also offers support of so-called cold-start meas- During ECU development important functions are frequently swapped
urements and internal ECU time stamps for tasks in cyclic data out to external simulation systems, so that they can be computed
acquisition. In cold-start measurement the ECU can be configured with less effort. It is not until the algorithms in the simulation model
so that it begins to periodically send out data immediately after have reached a certain maturity level that the developer generates
being activated, i.e. the Master does not need to initiate this from them a source code that is compiled together with other ECU-
explicitly. If an internal ECU time stamp is being used, it is not the relevant codes and flashed in the ECU. However, even before this
time of receipt that is relevant for later evaluation in the measure- occurs so-called “bypassing”, a coupling between a real ECU and its
ment and calibration system, rather it is the time at which the data model, is desirable so that tests and optimizations can be made inde-
were created in the XCP Slave. This eliminates uncertainties attrib- pendent of the hardware at an early point in development.
utable to possible delays in the transmission process, e.g. under In bypassing with XCP, the Master reads data from the ECU by
conditions of insufficient bus bandwidth or high load. DAQ, passes the values to the model as input values and sends the
model’s results back to the ECU by STIM. Noteworthy in this context
Optimizing characteristic curves and maps is that normal PC platforms running the MCD tool CANape are suffi-
cient for bypassing and modeling. This is good news, since solu-
Besides control algorithms based on mathematical models, ECUs tions based on special real-time hardware would be many times
also utilize characteristic curves and maps composed of discrete more expensive and would only be available in limited numbers in
interpolation points. To achieve desired system behavior, such development departments. CANape, as a highly optimized XCP Mas-
characteristic value tables are usually set up and optimized experi- ter, simultaneously handles communication with the real ECU and
mentally, e.g. at the test bench. A2L files serve to describe the with the model running on the PC (Figure 4). The ECU parameters
measurement variables and calibration parameters. The descrip- and model parameters can both be calibrated via CANape and XCP.
tion 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,

Figure 3:
Communication between Master and
Slave.
CTO = Command Transfer Object
DTO = Data Transfer Object

4/13

29 Press Book_Seite_4-10_4-15.indd 5 09.02.2010 13:28:07 Uhr


Flashing via XCP 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
XCP also offers benefits to the user in programming ECUs. The data an ECU calibration tool since 1996, is continuously updated as an
in the ECU’s flash memory are only reprogrammable using specially XCP Master to the latest level of XCP standardization based on
prepared flash routines, which must also reside in the ECU. In prin- Vector’s active participation in ASAM working committees. CANape
ciple, two approaches are conceivable: In solution 1, the flash rou- is the first tool on the market to have an XCP-on-FlexRay interface.
tines are stored permanently in flash; first, this wastes memory, In the development of the first production vehicle with FlexRay,
and second, it presents a security issue for delivered vehicles. In the BMW X5, this was a crucial factor in the decision by BMW engi-
solution 2, a PC tool only loads a flash kernel to the microcon- neers to rely on Vector’s XCP stack and CANape for calibrating the
troller’s RAM via XCP if it is needed for reprogramming. Besides con- damper control system.
taining the flash routines for erasing the flash memory and rewrit-
ing data, the flash kernel also contains its own bus and SCP drivers
for communicating with the PC tool over the bus interface. Translation of a German publication in
Elektronik automotive, 4/2007
Summary

XCP is a standardized and universally applicable protocol with much Literature and Links:
[1] www.asam.net
rationalization potential. It is not only used in ECU development,
[2] www.vector.com/canape
calibration and programming; it is also used to integrate any
[3] www.vector.com/downloads/drivers/xcp.exe
desired measurement equipment for prototype development, func-
tional 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 inde-
pendence from tool producers with proprietary solutions, and reus-
ability of components.

Figure 4:
Bypassing: Use of a standard PC with
CANape as a test system.

4/14

29 Press Book_Seite_4-10_4-15.indd 6 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 spe-
cialized in measurement and control engi-
neering as well as information and automati-
on 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” pro-
duct line.

4/15

29 Press Book_Seite_4-10_4-15.indd 7 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 From a technical perspective, it made sense to implement a mod-
operating at 77 GHz is the “sensory input“ for many safety-related ular layout of the measurement system and to make use of a stan-
and driver assistance systems. They include various versions of Pre- dardized PC interface. Development of a near-production ECU
dictive Safety Systems (PSS) and Adaptive Cruise Control (ACC). enabled a simple transition from development to production later
These smallest radar sensors in automotive industry, used in pro- on. To acquire the large number of measurement signals, up to
duction vehicles since the beginning of 2009, are distinguished by 100,000, without errors, a data rate of at least 4 MB/s is necessary
their long acquisition range of 250 m and their wide aperture angle while affecting the processor as little as possible.
of up to 45°. Together with a favorable price the application area is
broadened from luxury class to mid-class vehicles and commercial Existing solutions: Low data rates and high CPU load
vehicles. This development posed enormous challenges for Bosch
engineers when it came to performing measurement and calibra- In solutions that utilize the standardized measurement and cali-
tion tasks. Along with options for measuring and logging data, it bration protocols [1] CCP or XCP-on-CAN, FlexRay, JTAG or SPI, a
was essential to have efficient methods for calibrating and flashing driver integrated in the ECU is responsible for periodically reading,
as well as bypassing. All of these applications require extremely copying and sending out the desired signal values. Due to the large
high transmission rates with low latency times. volume of data to be measured, the driver requires RAM memory

4/16

30 Press Book_Seite_4-16_4-19.indd 2 09.02.2010 13:26:12 Uhr


and processor resources that have limited availability. In addition, modular VX1000 system developed by Vector (Figure 1). The base
there is increased loading of the data bus, which impacts the ECU module primarily consists of a FIFO buffer, Dual-Port RAM (DPRAM)
software in a negative way. Measurement data rates range from and XCP Engine that also has dedicated RAM. Write accesses to data
50 KB/s for CAN up to maximum values of 400 KB/s for FlexRay, within the two user-definable memory areas are transferred to the
JTAG and SPI (Table 1). FIFO buffer in the base module via the HSSL connection and the
debug interface. The data are further processed and written to the
A high-performance debug interface on the micro- DPRAM there. From a logical perspective, since this data is identical
controller opens up new possibilities. to the data stored in the ECU, the DPRAM always contains a current
mapping of the data, mirroring memory areas in the ECU. The cru-
Bosch decided to join together with specialists at Vector to concep- cial aspect of this approach is that all measurement processes occur
tualize an entirely new measurement and calibration system. As a via the mirror memory. To initiate a measurement and thereby initi-
measurement interface it utilizes the Data Trace Interface, which ate data transfer, it is sufficient to have the ECU write an event
an increasing number of modern microprocessors are equipped number to a predefined memory address that is allocated to the
with for debugging purposes. More specifically, this is a standard- measurement data. At precisely this time point, the connection
ized Nexus Class 3 Interface, which can communicate every change between the FIFO and DPRAM is disconnected, “freezing” the mem-
in the ECU’s memory to the outside world with minimal processor ory map at the trigger time. This keeps the data to be measured
load. constant over the measurement period. The XCP Engine now pro-
The fundamental idea of this approach is to acquire data from cesses the data according to the protocol.
the ECU via the debug interface and route it to an external meas- A transmission rate of up to 5 MB/s was achieved for the XCP-on-
urement adapter via a special high-speed cable. The data are trans- Ethernet connection between the VX1100 measurement adapter
mitted 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 standard-
ized 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 error-
free 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 pro-
ject at Bosch.
Figure 1:
Measurement adapter with mirror memory The VX1000 system is distinguished by very high meas-
urement data rates and very low software modification
A HSSL (High Speed Serial Link) cable up to 5 m in length connects requirements and effects on ECU execution time.
the POD to the VX1110 base module (measurement adapter) of the

ECU interface ECU software- ECU RAM- Measurement ECU execution Bypass latency
modification reqmt. data rate time effects time
CCP/XCP on CAN CCP/XCP driver 1–2 KB 50 KB/s Moderate High
software
XCP on FlexRay XCP driver software 2–16 KB 50–400 KB/s Large Moderate
XCP on JTAG/SPI Tables for DAQ transfer 4–16 KB 200–400 KB/s Large Moderate
via software
Data trace VX1000 Low None 5,000 KB/s Very low Low

Table 1: Comparison of different methods of measurement data acquisition

4/17

30 Press Book_Seite_4-16_4-19.indd 3 09.02.2010 13:26:13 Uhr


and the measurement and calibration tool on the PC. A highly fulfilled all expectations set in the Bosch project. Last but not
robust, temperature-resistant HSSL cable was used to ensure abso- least, along with good cooperation between the two companies,
lutely error-free data transmission in the engine compartment. In the CANape tool for measurement, calibration and diagnostics
case of transmission errors, a retransmission protocol provides for made an important contribution to successful project completion.
quick repetition of data packets. CANape is primarily used to optimally parameterize ECUs. In the
A look at the system’s performance demonstrates that the effort development and optimization of driver assistance systems like
was very worthwhile. The VX1000 measurement system impresses ACC, the CANape Option Advanced Multimedia offers specialized
with a measurement data rate of up to 5 MB/s, it enables a write capabilities. Among other things, it lets users display objects
rate of about 1 MB/s and handles the 100,000 signals of the Bosch detected by the system in a perspective view in time-synchronously
application effortlessly. The precision of the time stamps is 1 logged video images, which gives them a reliable means for verify-
microsecond, while bypass turnaround times of 300 microseconds ing object detection algorithms.
were attained.
Other application options and outlook
From laboratory simulations to rapid prototyping
The standardized XCP-on-Ethernet protocol can be used with both
These properties make the system ideally suited for the two primary the VX1000 product line and other measurement and calibration
applications at Bosch. The first application is bit-precise simulation tools. In the case of measurement and calibration tasks in the
of real scenarios in the laboratory. This involved feeding certain engine compartment, the VX1000 is not really an off-the-shelf
scenarios into the simulation without requiring real vehicle drives. product, since the harsh environmental conditions and limited
The second application, bypassing, is used to execute and test installation space generally require custom modification of the ECU
functions outside of the ECU. connection. In the framework of project work, Vector can work out
The described measurement system fulfills all requirements nec- individual solutions in close dialog with its customers. Devices cur-
essary for the LRR development, and it is now being used in other rently supported, besides the Freescale PowerPC, are the TMS570
projects at the Bosch company. Compared to classic measurement from Texas Instruments and the Infineon TriCore processors with
principles, the VX1000 solution offers performance increases by a DAP interface which are widely used in engine controllers
factor of 10 to 100 in all disciplines. The effect of measurements on (Figure 2). DAP enables a cost-effective solution via a plug con-
the ECU, with CPU loading of less than 1%, lies significantly below nector on the mini-PC-board connected to the ECU. Cycle times of
usual values. The modular layout of the VX1000 system assures 50 microseconds are possible with the measurement and calibra-
cost-effective re-use as a measurement technology solution in sub- tion system. These requirements are relevant in the development of
sequent projects, even with different microcontrollers. vehicles with electric/hybrid drives, for example.
Based on acceptance of the VX1000 system among automotive
The right solution for any required measurement data OEMs and suppliers, all sorts of extensions and new features will be
rate offered in the near future. They include plans to support additional
processors. Well-known semi-conductor manufacturers have
The VX1000 system completes Vector’s product line of measurement approached Vector seeking recommendations on how to adapt their
and calibration tools at the top end of performance. Because it processor architectures in the direction of optimal measurement
could reach previously unattainable measurement data rates, it 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

30 Press Book_Seite_4-16_4-19.indd 4 09.02.2010 13:26:13 Uhr


QUANTUM LEAP IN MICROCONTROLLER MEASUREMENT TECHNOLOGY

Literature references:
[1] XCP protocol: www.asam.net Andreas Riedl (Dipl.-Ing. (FH))
[2] Presentations by Riedl, A. and Kless, A. at the Vector Congress 2008. is Project Leader for engine controllers in the
Download at www.vector.com/veco08 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 “Measure-
ment and Calibration” product lines.
E-mail: alfred.kless@vector.com

4/19

30 Press Book_Seite_4-16_4-19.indd 5 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 combina-
tions. 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, applica- MATLAB console, or modifying an M-script and running it. To visu-
tion functions are checked in an iterative process. This involves alize the signal responses that occur when the model runs in Simu-
repeated runs of the model in Simulink from The Mathworks. link, the user instruments the model by attaching scope blocks to
Depending on the results, the developer may add function blocks each of the desired signals.
by drag-and-drop operation from libraries. These blocks are Use of the standardized XCP measurement and calibration pro-
parameterized either directly in the function block with a numeric tocol gives the developer a considerably more user-friendly way to
value or by defining a parameter and its value on the MATLAB con- efficiently manage parameters and measure signals from the Simu-
sole. To modify an existing parameterization, the same steps are link model without instrumentation.
executed again, either by looking for a block in the model and
changing its value, setting the parameter and its new value on the

4/20

31 Press Book_Seite_4-20_4-23.indd 2 09.02.2010 13:23:35 Uhr


Communication via XCP-on-Ethernet identification because the application’s data objects do not yet
have a real ECU memory address. After instrumenting the model,
The ASAM protocol XCP (Universal Measurement and Calibration Pro- using it with CANape is easy and efficient because it is possible to
tocol) has become established as the preferred solution for measur- generate a CANape project directly from the configuration of the
ing and calibrating applications in ECUs. This approach gives appli- block’s dialog in Simulink and start CANape with the created
cation engineers convenient access to measurement data and project.
parameters in the ECU via standard bus systems at runtime.
An ASAM standard A2L database (ECU description file) provides Numerous measurement and calibration functions
all the information needed to access parameters and signals in the accelerate model optimization
ECU. It contains descriptions of relevant data objects within the
ECU’s software, such as characteristic values (parameters, charac- The user visualizes the desired measurement parameters in the
teristic curves, maps) and measurement variables. The database measurement and calibration tool CANape – independent of the
also connects the object names to their memory addresses in the hierarchical organization and without further instrumentation of
ECU and provides conversion rules for physical interpretation of the the model. It is possible to display any of the input or output vari-
raw data. Using such a database, measurement and calibration ables of the model blocks and have their time responses displayed
tools can be used to acquire signal data or tune parameters as in graphic form. Parameters and signals can also be conveniently
desired by the user. Only a protocol driver is needed in the ECU; it displayed and calibrated right in the visualization of the model
enables memory access at the ECU’s runtime. (Figure 2). Simulink users will feel right at home in the familiar
In the “Simulink XCP Server” option for the CANape measurement model representation that does not require conversion. In the
and calibration tool from Vector Informatik GmbH, an XCP driver is model, a modified parameter is passed directly to the XCP Server
integrated into the Simulink model. As a result, the model is via XCP. It adjusts values in the Simulink blocks and in the base or
treated like a virtual ECU. The effort required to integrate the XCP model workspace; this is equivalent to manually setting the values
driver is minimal: a single block from the Simulink CANape library via the MATLAB console.
is dragged and dropped into the model. Settings of the XCP trans- The function developer can change parameters of a full Simulink
port layer – such as the host name and server port – can be config- model, or those of one or more subsystems, easily and convenient-
ured in the block’s dialog. They are necessary, since the “XCP-on- ly. This provides a way to test and optimize a Simulink model with
Ethernet” protocol is used to interconnect the measurement and different parameter sets. CANape supports different file formats
calibration tool with the Simulink model (Figure 1). here. Once the model has attained the desired maturity level, the
After this parameterization step, the XCP Server is ready to use. relevant parameters are saved to a parameter set file. The parame-
The model’s A2L description file is generated from the block’s dia- ter set management feature of CANape’s CDM Studio (Calibration
log. A virtual address is assigned to each Simulink object there. Data Management) is used to compare individual versions created
This is how the Simulink XCP Server explicitly implements address- during model optimization and merge parameter subsets or work
oriented XCP operation for the Simulink objects. The user then packets to obtain optimal settings for the entire model. These set-
selects objects in CANape in the usual way – by their names. An tings may be exported in the form of a MATLAB M-script so that
object’s address is read-in from the A2L and is sent as information they can be used directly as a new version level in the MATLAB/
to the XCP Server in the model. This means that for data objects in Simulink development environment (Figure 3).
the XCP Server, the address in the A2L file is only leveraged for

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 gener-
ated A2L file.

4/21

31 Press Book_Seite_4-20_4-23.indd 3 09.02.2010 13:23:37 Uhr


MATLAB/Simulink as Time Master Summary

Simulink models may run either slower or faster than real time, The implemented access to MATLAB/Simulink models via XCP in a
depending on their complexity and computer performance. This measurement and calibration tool simplifies the work of function
makes time stamps from Simulink indispensable. With each simula- developers considerably. For example, the model is automatically
tion step in Simulink, the associated time stamp is sent via XCP. instrumented via XCP, and this replaces the very tedious process of
Consequently, variations in the amount of the time needed for the manual instrumentation. As a universal front-end for measurement
simulation steps are irrelevant. Each simulation step corresponds and calibration tasks, CANape offers added convenience in the test
to one time unit, regardless of how much real time is needed for it. phase of models in Simulink. When XCP is used as a universal proto-
In the process, Simulink acts as a time master, and the measured col over the entire development process, this reduces overall pro-
data sent out by the model can be visualized in CANape at simula- cess complexity. The function development process is simplified
tion speed. Depending on the complexity of the model, sensor data and accelerated, since just one protocol, one description file, and
from a one or two hour real test drive may be computed in just a one tool are used for all measurement, calibration, and stimulation
few seconds or in minutes. If a user wishes to simulate especially tasks.
large and complex models, standardized communication with XCP-
on-Ethernet enables better computing performance, since two sep-
arate 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, cost-
intensive test hardware entirely.

Figure 2:
Efficient analysis of model behavior
by convenient navigation and quick
access to objects of the Simulink
model in CANape.

4/22

31 Press Book_Seite_4-20_4-23.indd 4 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

31 Press Book_Seite_4-20_4-23.indd 5 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. Today’s 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 on smaller turbochargers, e.g. on the Smart car, they may even
comes to fulfilling requirements for low fuel consumption, low haz- reach 300,000 rpm. Accordingly, the challenges in the develop-
ardous emissions and quality over long service life, while simulta- ment of turbochargers lie in the areas of materials engineering,
neously improving driving dynamics. Today, 98% of diesel vehicles cooling, bearings and high-precision manufacturing/balancing of
are equipped with turbochargers in the passenger car area, and on the rotating components.
trucks approx. 80 %. With the introduction of direct injection, tur- The company BorgWarner Turbo Systems with headquarters in
bocharging is also being used more frequently to improve the effi- Kirchheimbolanden, in the German state of Rheinland-Pfalz, is one
ciency of gasoline engines, although the considerably higher of the leading producers of turbochargers; it manufactures about
exhaust temperatures make it essential to use higher grade materi- 3.5 million charging systems annually in Germany and about 6 mil-
als that are more expensive. lion worldwide. According to company information, BorgWarner in
Kirchheimbolanden currently has the most advanced development
Development competence and innovative force in demand center for turbochargers in the world. Besides various standard
products for diesel and gasoline engines, its product line also
When a gasoline engine is driven at high power output, the turbine includes advanced developments with multi-stage control of charg-
can become white-hot at exhaust temperatures of up to 1050°C. ing systems as well as the eBooster concept.
Simultaneously, charger speeds typically reach 220,000 rpm, and

4/24

32 Press Book_Seite_4-24_4-27.indd 2 09.02.2010 13:24:51 Uhr


From the “turbo hole” to controlled charging control concepts that are provided to the customer for use on test
benches or in test vehicles.
Due to its operating principle, high startup torque and high maxi-
mum power are mutually exclusive in simple turbocharger designs. Working efficiently on the visualized model
That is, either a compact system is constructed for high charge
pressure at low engine speeds or a large system optimized for high In calibrating prototypes in the engine or vehicle, Vector’s CANape
speeds is constructed that neglects the desired dynamics in the measurement, calibration and diagnostic tool performs valuable ser-
lower speed, which is then called a turbo hole. vice. CANape is a powerful ASAM-conformant tool for all tasks relat-
Over the course of time, extended charging concepts have been ed to ECU calibration. Via physical interfaces such as CAN, FlexRay or
developed to overcome this handicap, e.g. the wastegate charger LIN and the standardized measurement and calibration protocols
equipped with bypass valve or the variable turbine geometry (VTG) CCP (CAN Calibration Protocol) and XCP (Universal Measurement and
that has become a standard today. Its adjustable vanes can be flex- Calibration Protocol), parameters can be measured from a PC at run-
ibly adapted to the exhaust gas flow. The latest developments time, and they can also be calibrated at runtime. At BorgWarner the
include two-stage controlled charging with two charger systems in capability of visualizing the Matlab/Simulink models in CANape is
series and the eBooster, in which an electrically driven flow com- particularly beneficial. Without requiring tedious searches through
pressor supports the turbocharger. documentation, the user can recognize – directly from the visualized
model – which parameters need to be adapted for the desired modi-
Turbochargers increase complexity of engine control fications. Search functions quickly lead to the desired parameters
and support convenient navigation through levels of the model.
The more refined the designs for charge pressure control, the In the production vehicle, the turbocharger application is run in
greater the requirements for turbocharger control. In addition, it the engine controller. The sensor and actuator systems are also
was necessary to acquire turbocharger speeds, exhaust gas back- connected here. During development, the turbocharger application
pressures and underlying parameters such as angles or positions of is swapped out to rapid prototyping hardware to enable flexible
actuator elements by sensors and process them in the ECU. Actua- testing of different software levels. This hardware consists of eval-
tors on the turbocharger consist of electrically or pneumatically uation boards with integrated power electronics for driving the
actuated components for adjusting the vanes or actuating flaps actuators. This may involve use of an actuator/sensor combination
and valves. that differs from the one in the production vehicle (Figure 1).
Control of the turbocharger is an integral component of engine CANape’s tasks here include calibration of the engine controller
control, and it therefore falls under the area of responsibility of the and the rapid prototyping hardware as well as visualization of the
automotive OEM. In view of rising complexity, however, OEMs are Simulink model. This is precisely how CANape closes the gap
relying on the support of turbocharger producers in implementing between the graphic representation of the model, which lets the
charge system control. In the development phase, BorgWarner uses user visualize the interrelationships between variables, and the
the Matlab/Simulink program package to design the relevant 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

32 Press Book_Seite_4-24_4-27.indd 3 09.02.2010 13:24:52 Uhr


created in optimization of the turbocharger application may of changes take effect immediately, without requiring the detour of
course be exported from CANape and read back into Matlab/Simu- making a modification in Simulink and then regenerating the code.
link. Since this layout is well-suited to both test stands and test These applications point out the capabilities of high-perfor-
vehicles, BorgWarner also implements it in road durability tests. mance development and diagnostic software in practice. CANape
makes part of the hardware equipment superfluous, saves on
Outlook for the future licenses for modeling software and noticeably accelerates develop-
ment progress due to fewer compiler runs. Calibration engineers at
To achieve an even more efficient solution, BorgWarner is now test- BorgWarner benefit from visualization of the Simulink model,
ing CANape in conjunction with a PC as a rapid prototyping plat- including all of its key parameters. Even heightened real-time
form. In this case, the system makes use of a DLL generated from requirements do not pose any problem here, since bypassing cycle
the Simulink model, which runs in the CANape context. The Matlab times as short as 2 ms are possible on PC platforms.
integration package supplied with CANape provides a CANape tar-
get with which the user generates CANape-specific code in the real-
time workshop. The generation provides the DLL with an XCP inter- Translation of a German publication in
face, so that the user can access the DLL in measuring and cali- Hanser Automotive, 11/2007
brating as if it were running on a rapid prototyping platform
(Figure 2).
Together with the PC that is present anyways, CANape replaces Links:
the prototyping hardware. If the XCP protocol is used in communi- Homepage BorgWarner Inc.: www.borgwarner.com
Homepage Vector: www.vector.com
cation with the ECU, CANape can simultaneously be used as a
Product Information CANape: www.vector.com/canape
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

Figure 2:
PC and CANape used as rapid prototy-
ping environment with supplemental
bypassing capability.

4/26

32 Press Book_Seite_4-24_4-27.indd 4 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

32 Press Book_Seite_4-24_4-27.indd 5 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 Munich’s 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 The evaluation electronics must also decide whether the acquired
of a vehicle, detecting vehicles ahead and maintaining the distance object should even be considered as a relevant control object,
to these vehicles desired by the driver. ACC systems also adjust the because the aperture angle of the radar sensors also detects any
car’s current speed to the traffic situation by automatically reduc- objects adjacent to the roadway. While radar scanning initially
ing engine torque, braking, and accelerating again, if necessary. To finds many objects, only the data of vehicles in one’s own lane may
maintain the correct distance to the vehicle ahead at any speed, be utilized for adaptive distance control.
ACC systems require very complex and precise computing algorithms. This is not a trivial task, since information from the radar sensor
What sounds relatively simple is in reality a great challenge for system is not always clear and unambiguous. Some of the radar
the development engineers, because a driving situation that a reflections are bumps in the road or simply false reports. This indi-
human driver is able to evaluate effortlessly is a nearly endless cates just how important it is to conduct a check of the acquired
array of numbers in an ACC ECU. A forward-looking radar unit sup- data (signals) based on visible evidence (the video image). The
plies coordinates of objects in cartesian form, i.e. in the X direction reliability and operating safety of this system, with its acceleration
(car’s longitudinal axis) and Y direction (car’s transverse axis), or and braking maneuvers, is in the truest sense a matter of life or
as polar coordinates with vehicle distance and azimuth angle. From death. Faulty behavior could lead to vehicle reactions that are
these, the ACC ECU concludes whether the distance to the car ahead incomprehensible to the driver.
is sufficient, whether braking needs to be initiated or whether it is For this reason, additional data are utilized at BMW to determine
possible to accelerate. the exact distance between vehicles and exclude irrelevant objects.

4/28

33 Press Book_Seite_4-28_4-31.indd 2 09.02.2010 13:28:19 Uhr


Besides dynamic driving data, data from GPS navigation are also To achieve optimal control functionality in the ECU, it is necessary
used, for example. to make numerous parameter modifications in an iterative process
Since there were no suitable products on the market, BMW ini- that can be performed online or offline with CANape. BMW utilizes
tially supported the ACC development process by a tool it had writ- the CANape Option “Advanced Multimedia”, an extension especially
ten in-house, which helped engineers reach an objective assess- designed for developing driver assistance systems. A core element
ment of the control algorithms. For production development, how- here is the Multimedia Engine, which displays ECU signals and
ever, BMW is now increasingly relying on standard products that information computed from them in 3D perspective in the video
can also be used by its suppliers. display. The relevant ACC coordinates can then be placed over the
video image as defined bitmap information in 3D perspective (Fig-
Tool-supported evaluation of sensor data and driving ure 2). Only by means of such visual “matching” is it possible to
impressions objectively assess the original mass of numbers. The BMW develop-
ers no longer just get coordinate information on the positions of
Ever since the CANape Option “Advanced Multimedia” (AM) became objects ahead of the driver; they can also immediately observe and
available, BMW has been using this tool more intensively on pro- verify them in a video image – from a bird’s eye perspective or side
jects and in production development. The tool’s standardized cali- view. Thanks to the saved information, it is possible to study real
bration protocols and flexible interfaces enable simple integration driving situations – which are normally never one-hundred percent
into an existing tool environment, leave room for engineering reproducible – in the laboratory and efficiently adapt the control
extensions and offer maximum future compatibility, e.g. for obtain- algorithms.
ing objective test results to evaluate the assistance systems of
suppliers. Environment detection with the camera
Even the base version of the measurement, calibration and diag-
nostic tool CANape from Vector is able to record all ECU-internal A coordinate transformation is necessary to represent object data
data time synchronously (Figure 1): from the ECU as geometric objects in the Video Window. To cali-
> Signals from CAN, LIN and FlexRay bus with the CCP/XCP calibra- brate the connected camera, all the BMW developers need to do is
tion protocols click eight reference points whose coordinates are known. Based on
> Peripheral measurement technology stored information, the tool automatically computes a coordinate
> Video and audio signals, and transformation for each detected object – from global coordinates
> GPS signals (optional). to image coordinates – and then displays the objects accordingly in
the video image.

Figure 1:
Time-synchronous real-time acqui-
sition and visualization of internal
ECU signals via CCP/XCP, and of sig-
nals from CAN, LIN and FlexRay bus-
es and external measurement
equipment via CANape.

4/29

33 Press Book_Seite_4-28_4-31.indd 3 09.02.2010 13:28:20 Uhr


Vector also offers a suitable camera for the system, since BMW is ional extensions. For example, today – at the request of BMW
not the only customer who values a universal and tested solution. developers – a so-called “driving tube” is generated with data from
ECU developers using CANape AM can use practically any desired the ACC ECU; it is then represented in the video image as either a
camera, from a webcam to a professional high-tech device, pro- bird’s eye view or a 3D perspective. This driving tube corresponds
vided that it has a USB or Firewire port and a DirectX interface. to a virtual driving lane that demarcates the presumed future path.
Optimal results are obtained with a camera that has a logarithmic This defines the corridor ahead of the vehicle that is relevant for
characteristic and 120 dB dynamic range that further enhances distance computation. Objects detected by the ACC system lying
image quality – both in tunnels and in direct sunlight. It is also outside the driving tube do not need to be considered in distance
possible to connect analog cameras via a Frame Grabber interface. control, and they are therefore represented by a different frame
Depending on the camera resolution, image refresh rate and num- color. Also part of the evaluation is highlighting traffic signs and
ber of cameras used, data might accumulate at rates of 20MByte/ traffic lights. Theoretically, the tool can be used to represent up to
sec or more. That is why developers work with reduced image reso- 50 different objects simultaneously.
lution; data compression units are also used to reduce the data Similarly high requirements are placed on the hardware. The
volume. volume of accumulating data and enormous computational
A number of standard pixel graphics are provided for object rep- demands on the computing platform are still a great challenge.
resentation in the video image. For example, a detected vehicle Previously, two PCs were needed to assure the specified perfor-
is represented by a rectangular frame, and other objects might mance. But this required manual data synchronization, since only
be shown as an “X” or a line. In the process, it does not matter one of the computers could access the internal ECU signals. Today,
whether the ACC information is obtained from radar, infrared or a dual-core computer platform is used for the ACC computations.
ultrasonic sensors. It is also easy to assign signals to an object with Since parallel recording of multiple video sequences and processing
the user-friendly GFX Editor for graphics (Figure 3). In another of FlexRay data place increased demands on the CPU, BMW experts
dialog of the GFX Editor, the user defines the type of visualization are seeking more balanced utilization of the two computing cores.
for the specific object type. This involves defining any objects
desired and linking them to the desired graphic symbols. In addi- Outlook
tion, users can also integrate their own graphics.
By visually comparing those objects detected by the ECU with the
Joint advanced development work real environment, BMW developers now have an easy and efficient
way to verify the object recognition algorithms of their ACC ECU.
For BMW, cooperative teamwork with the tool producer is a prereq- Cooperation between BMW and Vector is bearing further fruit, e.g.
uisite for developing intelligent high-end systems. In this project, improved processor loading of dual-core and quad-core computing
good cooperation has led to ideas that have spawned real funct- 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
bird’s eye perspective and overlay
on video image in the Multimedia
Window

4/30

33 Press Book_Seite_4-28_4-31.indd 4 09.02.2010 13:28:20 Uhr


OPTIMIZING DRIVER ASSISTANCE SYSTEMS

developing parking assistance systems. In the next few years, safe- Lorenz Eisenknappl,
ty systems will also be implemented based on environmental data Vehicle Dynamics Development: Team Leader for Control System
acquisition. They require even higher levels of computing perfor- Measurement Technology, BMW AG
mance due to the need for comprehensive detection of the sur- Walter Kagerer,
roundings and networking of active safety systems to Adaptive Vehicle Dynamics Development, Driver Assistance and Active Safety,
Cruise Control sensors. CANape AM will also let BMW developers ACCSnG, ACC and DCC Calibration, BMW AG
focus entirely on their core tasks in the future: considerable
Harald Koppe,
increases in driving convenience and further safety improvements Vehicle Dynamics Development: Measurement Technology for
in highway transportation. 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 & Calibra-
tion” 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

33 Press Book_Seite_4-28_4-31.indd 5 09.02.2010 13:28:20 Uhr


34 Press Book_Seite_5-00_5-03:Press Report 1 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 de-
velopment of automotive electronics will pla-
ce signif icant new demands on underlying
base technologies. In spite of growing func-
tionality 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 develop-
ment, data management and transfer of software modules into a control module’s flash
memory will continue to gain in impor tance.

Without fur ther advances in standardization it no longer be An ECU for multiple applications
possible to master the growing complexity of automotive A clear trend in automotive networking is reduction in the
electronics. In the 1990s automotive OEMs such as Daimler- number of ECUs in a vehicle. Today up to 40 ECUs operate in a
[1]
Chrysler went to great ef forts to establish the OSEK embed- luxury automobile. To permit implementation of even more
ded operating system as a binding standard for in-house de- functions, in the future consistent ef forts must be made to-
velopments and supplier components. Today the real-time ward running as many applications as possible within the
and multitasking capable operating system is used by auto- same control module. The OSEK multitasking operating sys-
motive OEMs and suppliers as the basis for improved code tem was specified for this purpose. However, other proper -
quality, good structur ing and integration of the components ties are required of the operating system for use in safety-
of dif ferent suppliers. In “Hersteller Initiative Software” critical systems and to integrate the software of dif ferent
[2]
(HIS) too the large automotive OEMs have come to an producers. For example, an application must not disturb oth-
agreement on uniform standards. Working committees have er applications running in parallel.
also been established in the areas of software, software
testing, process assessment, simulation and tools as well as Always in demand: The right timing
flash programming. The AUTOSAR (Automotive Open System One of the focal points in advanced development of em-
Architecture) Consor tium is responsible for the standards of bedded operating systems, for future OSEK versions and
future vehicle generations. AUTOSAR, is the ability to monitor software behavior relating
to timing and memory accesses. The most advanced methods
OSEK: Flexible and calculable for monitor ing timing are provided by AUTOSAR-conformant
A number of OEMs have cer tified OSEK implementations. Ap- implementations. Methods such as “Execution Time Enforce-
plications of the “osCAN” OSEK implementation, for exam- ment” and “Arrival Rate Enforcement” provide a mandatory
ple, range from normal ECUs to multi-bus gateways and in- minimum time budget for low-prior ity tasks too; these
ter face hardware. In the Vector Inter face for MOST VN2600 methods not only detect errors, they can also clearly identify
the per formance capabilities of osCAN were put to the test their sources.
under a 133 MHz Altera Excalibur controller processing up to
35,000 Events/s, which corresponds to a data throughput of Reliable boundaries for memory protection
1.7 MByte/s. At gateway producer K2L osCAN-based solu- In the future memory protection functions will restrict a
tions have demonstrated fast reaction times and precise tim- task’s access to the memory space assigned to it. This is es-
ing. pecially impor tant to prevent write accesses to other data
segments, detect stack overruns, and prohibit execution of

5/0
34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 2

incorrect code. On the other hand, tasks belonging to the applications and of fer a maximum level of reliability. A relat-
same application need to be able to access the same memory ed proposal for handling this issue in AUTOSAR is currently
areas, and special system functions such as drivers could re- being discussed in a working subcommittee.
quire unrestricted memory access. A distinction is made here
between so-called “Trusted Applications” with full access Better hardware support in the future?
rights and “Non-Trusted Applications” with restricted access The cited timing and memory monitor ing functions can only
rights. These names can lead to some confusion: Non-trust- be implemented ef ficiently with suitable hardware support.
ed Applications are stored programs that cannot really cause What are needed for memory protection are Memory Protec-
any damage. tion Units (MPUs) that are tailored to the needs of automo-
tive applications in terms of options of fered for number and
It is good design practice to place functionalities in Non-Tru- sizes of memory blocks. In many cases today the smallest
sted Applications whenever possible. Vector Informatik units that can be managed are blocks 16 kByte in size. In the
therefore of fers implementations that also permit calling of automotive embedded field, however, substantially smaller
Non-Trusted Functions. They are intended for safety-critical memory units are needed.

Figure 2: osCAN TimingAnalyzer enables simulation of scheduling tables (schedules) and computation of sched ulability

5/1
34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 3

Essentially the hardware requirements of current and future from Vector Informatik save the flash data together with ref-
OSEK real-time systems can only be fulfilled by a complete erences to the flash jobs in a ODX flash data container.
redesign of today’s processor cores. Desired features are cur- In some cases it may be necessary to enable modification of
rently being negotiated with semiconductor producers. flash data in the field by means of a post-build process. In
Among the most impor tant requirements, besides the named this context it is impor tant to recalculate checksums and
monitor ing functions, are an Interrupt Controller for dif fer- signatures, in addition to other parameters, and to send
ent interrupt levels with low latency times, hardware support them to the flash bootloader dur ing a flash update. The
in task switching, and processor cores with as few registers CANape Graph and CANdito tools, both online and off line
as possible. post-build processes can be handled in an elegant way, whe-
reby a script language optimized for flash and diagnostic
Can error-free embedded systems be developed? tasks is very helpful.
Interesting possibilities for master ing industrial complexity
are being researched in ongoing projects involving the in- Managing dif ferent memories in the ECU
tensive application of mathematics to the engineer ing scien- An impor tant topic in reprogramming is the management of
ces. Systematic analytical methods enable detection of er- dif ferent memory types in an ECU. Rising complexity, e.g. in
rors in real-time systems that would other wise not even be multiprocessor or distributed systems, goes hand in hand
revealed in extensive testing. Scientists on the Ver isoft pro- with greater memory requirements and the use of dif ferent
ject have taken this one step fur ther in concluding that it is types of memory. Some conventional nonvolatile memory
possible to develop error-free embedded systems and elec- devices have very dif ferent physical character istics. Among
tronic components. Entire systems consisting of hardware, the impor tant dif ferentiating character istics of nonvolatile
software, operating system communication, applications,
etc., might be universally ver ified by methods of formal ver i-
fication.

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 re-
quirements 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 Figure 4: Flash programming
processes in standardized formats. For this purpose, tools

5/2
34 Press Book_Seite_5-00_5-03:Press Report 1 09.02.2010 13:11 Uhr Seite 4

TRENDS IN EMBEDDED DEVELOPMENT

memory types are: Size of the write segment, size of the era-
se 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. Be-
ginning about 2008 new memory products are expected that
are based on FeRAM (ferro-electric), MRAM (magneto-resist-
ive) 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 Memo-
ry Driver Inter face that is experiencing growing support
from semiconductor producers. The inter face provides func-
tions for initializing, de-initializing, erasing, programming
and reading data. In an implementation based on the HIS in-
ter 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 us-
er benefits from maximum flexibility in accessing dif ferent
memory types, including access by SPI (Serial Peripheral In-
ter 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. There-
fore 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 com-
pression 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.
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 Embed-
ded Software Components product line.
[1] OSEK stands for “Of fene Systeme und deren Schnittstellen für die Elek- Tel. +49-711/80670-413,
tronik im Kraftfahrzeug” (Open Systems and their Inter faces for Elec- Fax +49-711/80670-111,
tronics in Motor Vehicles). E-mail: peter.liebscher@vector-informatik.de
[2] “Hersteller” = Producer or OEM

5/3
35 Press Book_Seite_5-04_5-07:Press Report 1 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

I The real-time and multitasking operating sys- as a standard for new developments, both for of the same company. In the MOST Interface
tem OSEK is the standard in automotive em- in-house developments and those at suppliers. VN2600 osCAN’s capabilities were put to the
bedded developments today. Its most important The company organized OSEK training cours- test under a 133 MHz Altera Excalibur con-
properties include low consumption of proces- es, created OSEK design guides and supported troller: its processing of up to 35,000 Events/s
sor resources and memory, and event-driven operating system producers. It also financed corresponds to a data throughput of 1.7 MB/s.
task management that effectively handles both one OSEK licence per supplier, whereby only
cyclic and non-cyclic program blocks. Contin- certified OSEK operating systems were permit- Requirements of an operating system grow in
uing advances in automotive electronics and ted. The costs of introduction reached a high parallel with the continuing penetration of elec-
the new HIS and AUTOSAR standardization point in 2002 and then dropped significantly. In tronic technologies. In particular the advance of
initiatives also place new demands on the the meantime OSEK has generated its own suc- safety-relevant applications in the vehicle, such
operating system. Areas of emphasis in future cess, and now most ECUs in the automotive as fully electronically controlled steering and
operating system versions will be timing and field run on OSEK operating systems. braking systems (X-by-wire), make determin-
memory protection. istic behaviour essential under peak loads and
Efforts have paid off: applications based on fault conditions. For example, the specification
In the 1990s the large automotive OEMs intro- OSEK have fulfilled expectations by their im- of OSEKtime will supplement the event-driv-
duced the OSEK/VDX operating system spec- proved code quality, structuring and the abili- en OSEK with a time-triggered variant.
ification with the goal of establishing a uniform ty to integrate components from different sup-
standard for software in electronic control pliers. At gateway producer K2L solutions with Fault tolerance, error detection mechanisms
units. The wide variety of proprietary embed- osCAN, the OSEK/VDX-conformant operating and memory protection also play an important
ded operating systems at numerous suppliers system from Vector Informatik, have demon- role in achieving system reliability. This has ac-
had proved to be an obstacle to smooth integra- strated fast reaction times and precise timing. quired special relevance, because in the future
tion in light of the growing significance of Last but not least, what has proven to be deci- an ECU will handle multiple applications run-
automotive electronics. Besides defining the sive for OSEK in conjunction with a table-driv- ning simultaneously. In “Hersteller Initiative
actual operating system core, OSEK also defines en interpreter concept are flexibility gains Software” (HIS; Hersteller = producer or OEM)
communication services and functions for leading to shorter development times, higher the large German automotive OEMs have
network management. quality and functionality and ease in creating come to an agreement on the standards need-
variants. Leading the way here were compar- ed to implement the named functions. Working
Since most automotive suppliers had already isons between OSEK with its preemptive committees have been established in the areas
committed to a preferred operating system be- scheduling and a fixed coded static approach of software, software testing, process assess-
forehand, automotive OEMs had to introduce with cooperative scheduling. The “osCAN” ment, simulation and tools as well as flash pro-
OSEK persuasively in some cases. Daimler- OSEK implementation has proven itself, not gramming. The AUTOSAR (automotive open
Chrysler, for example, made OSEK mandatory only in ECUs but also in the interface hardware system architecture) consortium is responsible

41 June 2006
5/4
35 Press Book_Seite_5-04_5-07:Press Report 1 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 exam-
ple, an application must not disturb other ap-
plications 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.

Progress has varied considerably in the various


development levels as a result of these efforts.
OSEKtime, specified since 2001 for time-trig-
gered 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 can-
not discern the causes for deadline violations.
For example, if the monitored task was inter-
Figure 2. Function block diagram with MOST interface VN2600 and an Altera Excalibur controller rupted by a higher-priority task, then the
monitored task is not really responsible for
being unable to satisfy the prescribed time win-
dow. In HIS-conformant OSEK extensions
memory protective functions are defined in ad-
dition to deadline monitoring. The most ad-
vanced 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 integrat-
ed options for run-time measurements.

Figure 3. Deadline monitoring to detect deadline violations. The error source of Task 2 is not found Memory protection functions restrict a task’s
in Task 1. 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 un-
restricted memory access.

A distinction is made here between so-called


“trusted applications” with full access rights and
“non-trusted applications” with restricted ac-
cess rights. These names can lead to some con-
fusion: 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 sys-
Figure 4. Tasks belonging to the same application must be able to access the same memory areas.
tem security and cannot provide identification
of errors or error sources. It is good design
for the latest standards for future vehicle gen- tions in the foreseeable future, it becomes practice to place functionalities in non-trusted
erations, whereby the HIS group is integrating clear why limiting the number of control mod- applications whenever possible. Vector Infor-
its results into AUTOSAR and is representing ules in the vehicle has become a pressing topic. matik therefore offers implementations that
uniformity interests there. When one considers This objective can only be achieved if multiple also permit calling of non-trusted functions.
that over 50 ECUs operate on a luxury automo- applications run on the same control module. They are intended for safety-critical applica-
bile today and that there appears to be no end The multitasking OSEK operating system was tions and offer a maximum level of monitoring.
to potential new automotive electronic applica- specified for this purpose. However, other A related proposal for handling this issue in

June 2006 42
5/5
35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 3

DEVELOPMENT TOOLS

AUTOSAR is currently being discussed in a the hardware requirements of current and fu- sible. Many of these applications consist of
working sub-committee. The cited timing and ture OSEK real-time systems can only be ful- drivers and interrupt service routines (ISRs)
memory monitoring functions can only be im- filled by a complete redesign of today’s proces- which in contrast to the workstation field
plemented efficiently with suitable hardware sor cores. Desired features are currently being belong to the application here. It is problemat-
support. What are needed for memory protec- designed together with semiconductor produc- ic that on today’s controllers the ISRs often can
tion are memory protection units (MPUs) ers. Among the most important requirements, only be disabled completely. In general,
that are tailored to the needs of automotive ap- besides the named monitoring functions, are an disabling mechanisms must be made more
plications in terms of options offered for num- interrupt controller for different interrupt lev- efficient in implementations, since this basic
ber and sizes of memory blocks. In many els with low latency times, hardware support in
cases today the smallest units that can be task switching, and processor cores with as few
managed are blocks 16 KB in size. In the auto- registers as possible. For hardware-related and
motive embedded field, however, substantially time-critical automotive applications what
smaller memory units are needed. Essentially, counts is the ability to react as quickly as pos- 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
35 Press Book_Seite_5-04_5-07:Press Report 1 09.02.2010 13:06 Uhr Seite 4

DEVELOPMENT TOOLS

function is executed very frequently. The quick reduced testing effort, productivity gains,
task switches by which real-time embedded sys- quality improvement and comprehensive sys-
tems “thrive” are currently given just rudimen- tem optimization. Scientists on the Verisoft
tary support in hardware. The majority of re- project have taken this one step further in con-
sources is consumed in saving and restoring the cluding that it is possible to develop absolute-
context. The context is made up of core regis- ly error-free embedded systems and electron-
ters, register banks, memory access registers, ic components. They turn to the methods of
floating point and arithmetic registers of the formal verification to verify entire systems con-
stack pointers, special peripheral units and a sisting of hardware, software, operating system
number of operating system variables. A fully communication, applications, etc. In coopera-
hardware-supported context switch would be tion with project partner Infineon, the TriCore
ideal here. 2 processor, the future flagship of the compa-
ny’s 32-bit microcontroller device line, offered
Furthermore, it has been shown that processors the first evidence that this innovative technol-
with a low number of registers offer better per- ogy could be applied to highly complex de-
formance. Many registers can only be used signs. The long-term Verisoft project set up
meaningfully in typical workstation environ- under the project leadership of Prof. Dr. Wolf-
ments, because that is where individual pro- gang J. Paul, of the University of Saarbrücken,
gram sequences run for a relatively long time is being supported by the German Federal
without interruption. A potential trend here Ministry for Education and Research.
could lead in the direction of so-called softcore
processors and to compilers that permit con- Foundations and base technologies have been
figuration of the registers used. Interesting pos- created for achieving reliable electronic systems
sibilities for mastering industrial complexity in the automobile. Specific challenges must still
are being researched in ongoing projects in- be overcome by controller producers. Apart
volving the intensive application of mathemat- from that it is the responsibility of automotive
ics to the engineering sciences. Systematic an- OEMs and suppliers to utilize the available
alytical methods can be used to reveal critical resources optimally. A powerful certified OSEK
situations in the time behaviour of an OSEK implementation or AUTOSAR-conformant
system that would otherwise not be found even embedded operating system, together with a
by extensive testing. In this context, tools universal tool-chain, will make it possible to
from the SympTAVision company enable tar- rationally master the complexity of future
geted searches for “bottlenecks” and “hot electronic development. I
spots”, informing users of worst-case situations.
The advantages of systematic analysis lie in

June 2006 44
5/7
36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 1

Current Challenges in Automotive Networking

The vision of cross-platform use of ECUs,


universal communication capability, in-
terchangeability and reusability of soft-
ware 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 two- modules. That assures stable networks and components essential to
day event sponsored by the specialist in developing automotive achieving reusability of total system solutions across vehicle lines
electronics, Vector. For the over 350 par ticipants meeting in Stutt- that have dif ferent Electrical/Electronic infrastructures. The global
gart, the themes of diagnostics, testing, quality and distributed challenges lie in attaining quality improvements with simultaneous
systems were of primary impor tance. There was general agreement cost reduction, creating new business models for handling software
that the cited visions and future goals could only be achieved by as an independent product with regard to issues of utilization
comprehensive standardization. The well-worn road will continue rights, pricing, product liability, etc., and realizing a professional
to be traveled, where the relative impor tance of software will con- organization with a high level of process matur ity.
tinue to grow compared to mechatronics and hardware. That is be-
cause in the future crucial innovations, specif ic functions and Activities at Volkswagen and Audi
brand-typical proper ties will be firmly based in the software area. The current network architecture in Volkswagen vehicles is based on
Mechatronic systems on the other hand will be responsible for basic a total of seven CAN buses plus LIN sub-networks and the K-line.
functions and emergency back-up systems for example. Currently the focus in standardization work and development ef -
This continued growth of electronic systems in the automobile must forts at VW is on standardizing the diagnostic exchange format per
however be achieved without increasing the number of control ASAM/ODX, working together with other leading automotive OEMs

Figure 1:
Cur rent network
architecture
at Volk swagen.

6/0
36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 2

in the HIS (Hersteller initiative Software) interest group, develop- placing CAN-B. With regard to acceptable bus load, the CAN bus has
ing and introducing AUTOSAR-conformant software components already reached its maximum in some instances. Therefore, begin-
and utilizing the FlexRay and MOST bus systems. ning in 2008, time-triggered FlexRay will assume cer tain challeng-
ing networking tasks in distributed systems. In 2009 FlexRay will
ODX has already proven its capabilities in a future-oriented joint be used in an extended application with more than three bus
project. The new generations of the Sprinter and Crafter vans from nodes. MOST has been transporting data in multimedia applications
DaimlerChrysler and Volkswagen are similar from the networking since 2003 on the Audi A8, and since 2006 on Volkswagen models
architecture perspective. An ODX converter processes the ODX diag- too. Additional implementations are planned [1].
nostic data generated by the Vector Tool CANdela by DC and uses it
to prepare the diagnostic data for VW. Suppliers: Generating customer utility instead of main-
taining variety
In introducing AUTOSAR, VW and Audi are taking the approach of AUTOSAR also simultaneously represents an oppor tunity and a chal-
gentle migration and are converting ECUs gradually, ECU by ECU. lenge for Tier-1 suppliers such as Bosch [2]. For suppliers the bene-
Initially there will be dif ferent “next generation” development lev- fits of a global de-facto AUTOSAR standard lie in the use of stand-
els of the standard software core, in which both AUTOSAR and VW ard platforms; this limits the number of versions and facilitates
modules are implemented simultaneously. Adaptation work is fo- cost-ef fective mass production. Suppliers can devote their energies
cusing on hardware-related areas such as the communication driv- entirely to generating customer utility and do not need to employ
er, I/O driver and memory driver as well as associated abstraction their development resources in numerous inter face modifications.
modules. After the last migration step, steps will be taken to thor-
oughly separate the application layer from the underlying layers, In implementation seemingly contrary requirements sometimes
such that it only accesses other system components via the AUTO- need to be satisfied. For example, on the one hand product lines
SAR Runtime Environment (RTE). should demonstrate unique competitive advantages, but at the
same time they should fit trouble-free into dif ferent system envi-
Cost and per formance considerations play a key role in decision- ronments. System modeling and system design must be kept sepa-
making processes for future network technologies. Volkswagen is rate in integrating the devices in a network of ECUs and bus sys-
trimming its large number of CAN networks: LIN and CAN-C are re- tems. This can only be achieved by very close cooperation with

Figure 2:
Future network
technologies at
Volk swagen.

6/1
36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 3

OEMs in design and evaluation of E/E infrastructures. Migration of At the Vector Congress it was made clear that to master the rising
today’s software architecture to AUTOSAR demands much innova- complexities involved in development, administration, data ex-
tive work by the supplier in adapting development processes, meth- change and process management, it is increasingly becoming nec-
ods, tools and ways of thinking. essary to turn to massive software support. Vector supports vehicle
In the development process ef forts must be directed toward creat- OEMs and suppliers in networking the described systems with a uni-
ing unambiguous def initions of inter faces, completing unfinished versal tool chain and software components, wherein continuous ad-
work and deliver ing results; precise software specifications that vanced development of the tools is always oriented toward the lat-
prescribe the depth of detail and development levels are essential. est specifications of standards.
All in all what is required are professional techniques of project and
quality management, project risk assessment and a high matur ity Literature references:
level among all partners. [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 sys-
Summary and outlook tem architecture from the perspective of an automotive supplier”,
Key goals of cross-OEM standardization ef forts are quality improve- Vector Congress 2006.
ment, cost reduction and ef ficient management of the continuously
growing software share in the value-creating process. The path to-
ward attaining these goals at OEMs and suppliers necessarily in-
volves developing and introducing system components that con-
form 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
36 Press Book_Seite_6-00_6-03:Press Report 2 09.02.2010 13:05 Uhr Seite 4

ECU Software

Accelerate Your Embedded


Software Development
with standardized basic software. Benefit from scalable soft-
ware modules for CAN, LIN, FlexRay, J1939 and CANopen used
successfully by many OEMs worldwide.

> Build upon OSEK- or AUTOSAR-conformant operating systems


Distr. Systems
which serve as the foundation for a stable implementation.
Development

> Create functionally reliable networks with the communica-


tion stacks that most developers rely on.
Test
> Use the Flash Bootloader to update your ECU software in a
ECU

controlled process and protect it from third party access.


> Focus on your application development tasks by using
AUTOSAR-conformant basic software modules.
Diagnostics

> Improve your efficiency with Vector‘s tailored consultation


and development services.
Calibration
ECU

Vector supports you with embedded software, configura-


tion tools and services throughout the ECU development
Software process.
ECU

Management More Informationen: www.ecu-software.com


Process

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. +49 7 11 8 06 70-0
www.vector.com
37 Press Book_Seite_6-04_6-09:Press Report 3 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 so-
called pre-compile configuration occurs. This enables ef ficient im-
plementation of configurations, e.g. var iants, by macros or C pre-
processor 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 com-
mands. In such cases, the configuration parameters must be stored
in RAM. In contrast to the configuration types already named, post-
build 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 configura-
tion 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 Figure 2:
layer model – which configuration options exist for CAN communi- Configuration classes in the layer model of an
cation modules. AUTOSAR ECU

Figure 1:
Configuration concepts in ECU development

6/4
37 Press Book_Seite_6-04_6-09:Press Report 3 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 parame-
ters 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 responsi-
ble 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 Figure 3:
software. A vehicle facelift for such ECUs of ten consists of just new AUTOSAR basic software modules with gateway
or modified routing relationships, for which all that is needed is a functionality
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 config- Nonetheless, it should be noted that in accordance with the
uration can be per formed in late development phases dur ing ECU AUTOSAR specification the PDUs must be routed immediately after
integration or even in the field. This approach is of special interest they are received. Consequently, the PDU router cannot per form
for gateway ECUs. send type or cycle time conversions. In some cases, however, such a
conversion is necessary. An example of this might be a FlexRay-CAN
The gateway ECU as flexible switchboard gateway that routes a PDU from a FlexRay cluster to a CAN network
The main purpose of a gateway ECU is to distribute communication as a CAN message. In this case, the gateway ECU must for example
data among the individual networks in a vehicle. According to the conform to minimum transmission delay requirements (debounce
AUTOSAR standard, var ious basic software modules of the ECU per - time) for the CAN message. In such cases, the PDUs are therefore
form this task. Which modules are used depends on the specif ic routed directly to the COM layer, which then assumes this task.
gateway functionality that is needed:
TP gateway
PDU gateway Another task of the PDU router is to route transport protocol data.
The PDU gateway is a part of the PDU router (Figure 3). It routes en- This comes into play, for example, if the extensive diagnostic data
tire data packets, known as Protocol Data Units (PDUs), from one of an ECU need to be automatically transferred from one network to
network to another. This principle assumes that the PDUs are de- another. This involves receiving the data via the Transport Protocol
fined identically on both the source and target networks, i.e. they (TP) and resending it. At first, the transmission occurs above the TP
must agree in length and contents. This means that data can also (Layer 4 in the ISO/OSI layers model), and this enables a conver-
be exchanged between dif ferent bus systems such as CAN, LIN or sion to dif ferent addressing methods and var ious bus systems. To
FlexRay. keep delays and RAM requirements in the gateway as low as possible,

6/5
37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 3

the TP gateway supports so-called “on-the-fly routing“: The gate- available for other purposes. However, the basic software modules
way does not wait until all TP data have been received, rather it al- are highly dependent with respect to their implementation. If the ba-
ready begins to resend the data at an earlier time point. Conse- sic software originates from dif ferent software suppliers, this var iant
quently, it receives and sends simultaneously. generates a high coordination needs and is therefore impractical.
In the fragmented var iant 2, the data structures are always placed
Signal gateway at a static position in memory. Here, at the time of design, an as-
Of ten just individual signals are needed on the other network. In sumption is made concerning the largest possible memory usage of
this case, the gateway does not transfer the entire PDU, but only individual data structures. In practice, some unused memory be-
sends individual signals to the other bus. To do this, it first disas- tween the data structures remains. With regard to runtime behav-
sembles a received PDU into individual signals, so that it can then ior, var iant 2 is more ef ficient, since no indirection is needed in
assemble them into one or more send PDUs. Besides modifying the data access. Despite the fragmentation, this var iant also of fers
signal composition and signal positions within a PDU, the send type advantages in terms of memory ef ficiency, since an indirection
and cycle time can also be changed. This method is also used when table is unnecessary.
a PDU should contain both routed signals and signals generated di- The use of post-build data structures has an enormous ef fect on the
rectly in the gateway ECU. design of the basic software modules. In the case of the pre-com-
pile configuration, for example, the separation of code and data is
Technical aspects of post-build configuration not required. This makes it easier to implement configuration set-
Data structures for the post-build configurable data essentially tings very ef ficiently with macros or preprocessor switches and to
have two dif ferent types of layouts (Figure 4). In the non-fragmented generate optimized C functions with the help of code generators.
var iant 1, the data structures are arranged one directly after anoth- The principle of the post-build configuration, on the other hand,
er in memory. The individual data structures are accessed via an in- requires strict separation of code and data for post-build parame-
direction table located at a static position. The data structures on ters. A generator is only available for generating constants tables.
the other hand may vary in size depending on the post-build con- The C functions are static. Figure 5 shows how the dif ferent config-
figuration. The remaining memory is a contiguous block that is uration concepts appear based on code examples.

Figure 4:
Data structures for post-build configuration

6/6
37 Press Book_Seite_6-04_6-09:Press Report 3 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 A tool chain for post-build configuration of gateway ECUs
messages. This information exists in the form of data structures in Besides the aspects of memory and runtime resources in the ECU,
the ECU’s memory. As a result, in gateway ECUs the communication the post-build principle also requires new processes to coordinate
layers in the software architecture take up a considerable share of configuration parameters between par ticipating development part-
memory and runtime resources. Even when the more ef ficient var i- ners and exchange them reliably. One impor tant source of support
ant 2 is selected, the post-build capable layout of the ECU typically here is a well-functioning tool chain. Figure 6 shows the tool chain
causes increased resource requirements. from Vector Informatik, which can also be used for post-build con-
figuration of gateway ECUs.

Figure 6:
Vector tool chain for
the post-build
configuration

6/7
37 Press Book_Seite_6-04_6-09:Press Report 3 09.02.2010 13:07 Uhr Seite 5

At the beginning of a development project, the ECU supplier sets Summary


up the project based on the Pre-Config1 parameter set. Vector pro- The post-build process provides flexibility when changes are made
vides this parameter set along with the base software delivery for in the communication description. Configuration is even possible in
the ECU, and it contains pre-compile parameters that do not have late development phases dur ing ECU integration or in the field. This
any ef fect on the post-build configuration. Examples of this are approach is especially useful for gateway ECUs, since it is possible
general settings and use of the Development Error Tracer (DET). to adapt them to modified network conditions without having to
In coordination with the ECU supplier, the automotive OEM provides change the complete application code. However, the increased re-
the Pre-Config2 parameter set and an initial network description source requirements must be taken into account. In any event, a
(database). The Pre-Config2 parameter set contains those pre-com- gateway ECU is an interesting candidate for the post-build process,
pile and link-time parameters that have an ef fect on the post-build at least dur ing the development phase.
process and need to be defined in advance. Examples of this are the
addresses of post-build data in the ECU, compiler options and maxi- Reference:
mum memory size (Flash and RAM). The initial network description, [1] AUTOSAR specifications: www.autosar.org

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 Hartmut Hörner
studied Electrical Engineer ing at the
networks are also described there.
University of Stuttgart from 1987 to 1992.
After wards, he worked as a software devel-
The ECU supplier uses the GENy tool to configure and generate the oper for ATM Test Systems. In 1998,
Mr. Hörner came to Vector where he is the
basic software using this input information. The routing informa-
team leader responsible for the development
tion is prepared in the form of generated data structures (tables) of embedded software components. Hartmut
for the individual basic software modules. This provides a founda- Hörner represents Vector on var ious standards
tion for developing the ECU based on the initial network descrip- working committees (OSEK, ISO, AUTOSAR).

tion.
Dur ing the actual post-build process, these tables must be regener-
ated and exchanged in the ECU. The basis for this is a modified net-
work 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 be-
havior 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 in-
formation is known to the automotive OEM, the OEM itself can also
per form the post-build process directly.

6/8
37 Press Book_Seite_6-04_6-09:Press Report 3 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

Vector Informatik GmbH


Ingersheimer Str. 24
70499 Stuttgart
Tel. +49 (0) 7 11 / 8 06 70-0
www.vector-informatik.com
38 Press Book_Seite_6-10_6-13:Press Report 2 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 Vehicle perspective


defined, in its Release 2.1, a practice-tested software architecture From the OEM perspective, basic platforms, technological plat-
that is used as a foundation for developing reusable applications. forms, etc. are being developed, from which the next generations
With publication of these specifications, in the future it will be pos- of cars will be derived. The underlying goal here is to integrate one
sible for all companies belonging to the AUTOSAR development and the same ECU in many vehicles and thereby reduce costs. At the
partnership to develop AUTOSAR-conformant components. Howe- same time, the quality and the stability of the vehicle electronics
ver, its practical implementation is not trivial. The transition from should be improved. This results in a dilemma between the impon-
individual software to standard software has to be well-planned derables of a newly introduced technology and the stability of the
and is cer tainly only conceivable if a stepwise approach is taken. product.
The AUTOSAR philosophy and description language create a diverse
environment for using standardized software. In practice, this may Architectural perspectiv
be a mixed installation of AUTOSAR and non-AUTOSAR components From the point of view of an ECU individual software components
or an integration of basic software for specif ic platforms by a num- are discernible. At the same time, two contradictory approaches are
ber of dif ferent software suppliers. For both types of implementa- being followed with regard to the base software of today’s ECUs. On
tion, it is necessary to clar ify and define the relevant constraints the one hand, many OEMs require specif ic software components or
from var ious perspectives. at least they specify them. On the other hand, control module pro-
ducers are striving internally to always use the same architecture
for a control module platform. Added to this is the fact that the de-
gree 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
38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 2

described by AUTOSAR. The goal here is to apply a standard to soft- Stage II - Replace:
ware that does not serve the purpose of competitive dif ferentia- Non-AUTOSAR components can now be replaced gradually by AUTO-
tion, thereby creating space for new innovations. Optimally, low in- SAR components without putting the overall architecture at risk or
vestment costs would be incurred by new tools, since those tools al- requir ing reprogramming of other modules. The goal here is to set
ready in service can for the most part be reused. up an AUTOSAR architecture and use the appropriate tools. Initiat-
ed in individual ECUs, in the end the entire vehicle is conceptual-
Clear migration strategy as factor in success ized with AUTOSAR software, starting with system design and end-
When these two perspectives are applied to a decision on introduc- ing with integration.
ing AUTOSAR, it makes sense to select a multistage approach.
Using the AUTOSAR architecture in designing new ECUs
Stage I – Set up the architecture and expand: As implied in Figure 2, essential parts of the individual software can
The first step is to compare the existing custom software and the also be reused in the framework of an AUTOSAR architecture. They
AUTOSAR architecture. After analyzing overlaps and integration po- are then linked to the application via an adaptation layer as a com-
tentials, a decision is made regarding which modules will be pre- plex device driver.
served and which ones can be replaced by standard software. At An overlap matrix shows the por tions in which AUTOSAR software
this stage it is recommended that a separating layer be introduced can be introduced without great risk. Primarily, the memory section
between application software and base software as well as a stand- and the IO hardware abstraction can be migrated smoothly. Cluster
ardized inter face. The so-called Runtime Environment (RTE) serves memory management in par ticular has very clear and easy-to-use
as the link for the necessary data exchange, and as a buffer with inter faces that enable its early migration to new ECUs.
defined inter face it enables modular programming without depend- In communication and diagnostics, on the other hand, there are
encies. This is how AUTOSAR components can be integrated without considerable overlaps between proprietary vehicle software and
making additional changes to the custom and application software. the standard modules of the AUTOSAR basic software. In the inter-
The custom software is linked to the system architecture via an Ad- est of stability in the vehicle, a more conservative approach is re-
aptation Layer to enable data exchange with the AUTOSAR compo- quired here. Many OEMs utilize platform ECUs, in which existing
nents via the RTE; see Figure 1. software modules are transferred to new vehicle models. One impli-
To minimize cost and ef fort and arrive at an optimal overall solu- cation is that the network and communications strategy cannot be
tion, it is helpful at this point to integrate the custom software in changed over the short term. In the case of an immediate migra-
the configuration tools. tion, 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 inte-
grated 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 fa-
ces help in implementing the standard software on the SPAL level
without af fecting the upper layers. This of fers an enormous advan-
Figure 2: tage with regard to reuse.
Integration of custom software in the AUTOSAR Vector Informatik utilizes the concept of Product Cluster ing here.
architecture. Based on AUTOSAR specifications, the products of fered range over
a number of layers and provide total solutions for memory, commu-

6/11
38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 3

nication, diagnostic and system areas. These are independently Summary


functioning areas, some of which can also be implemented without When considered from dif ferent points of view, a stepwise introduc-
AUTOSAR architecture. Cluster memory for example can be integrat- tion of the standard components defined by the AUTOSAR develop-
ed quickly and easily in many ECU applications; see Figure 3. ment partnership into an individual company’s software architec-
ture appears to be the correct path. This approach guarantees qual-
Support by tools ity and consistency. Proper tools support this process. Gradual mi-
An impor tant pillar in the introduction of AUTOSAR relates to the gration instead of an immediate total conversion leads to an overall
tools. They must be able to operate the AUTOSAR inter faces, yet AUTOSAR solution in the vehicle that minimizes risks. Vector’s ex-
they must remain open to integration of third-par ty components. pertise and many years of experience lend support to this process.
Above all, configuration tools should be able to master this chal-
lenge and also support the user in validation of the system configu-
ration.
The tool world servicing AUTOSAR can be subdivided into three cat- Peter Schiekofer
egories: Design, configuration and test/simulation. Above all, suit- (Graduate Engineer) has been employed at
Vector since May 2006. He manages Vector’s
able test instruments are an essential component for successful de- Regensburg subsidiary and is responsible for
velopment. An ECU operates as a part of a whole. Checking for and advanced technical development of AUTOSAR
assur ing consistency in the overall system requires a high-per form- solutions. As an active working par ticipant
on Working Packages WP 1.1.2 and WP 20 of
ance simulation tool. Vector Informatik GmbH has come to grips the AUTOSAR Development Partnership he is
with these requirements and can make a contribution to the suc- directly involved with the new technology.
cess of AUTOSAR with its comprehensive tool solutions such as the Tel. +49-941/20865-101,
Fax +49-941/20865-111,
DaVinci Tool Suite, MICROSAR Configuration Suite and CANoe. Sup-
E-mail:
port in the context of project work and consultation complement peter.schiekofer@vector-informatik.de
the products of fered.

Figure 3:
Vector of fers MICROSAR, which
contains the entire range of
AUTOSAR-BSW including RTE.

6/12
38 Press Book_Seite_6-10_6-13:Press Report 2 09.02.2010 13:10 Uhr Seite 4

6/13
39 Press Book_Seite_6-14_6-17:Press Report 4 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 elec-
tronic 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. is abstracted and subdivided into several layers (Figure 1). The con-
Growth in the number of complex vehicle functions is making the nection to the actual microcontroller, i.e. the physical foundation,
development of automotive electronics increasingly more extensive is represented by the Microcontroller Abstraction Layer, which maps
and complicated. Customer wishes, e.g. for more var iants and the microcontroller’s functions and periphery. It defines inter faces
equipment variety in the vehicle, as well as non-functional require- for memory, the I/O driver and its communication connections. In
ments such as diagnostic capability and availability, are requir ing this layer, features that the microcontroller does not offer may also
more intensive ECU development processes. Vehicles, in par ticular be emulated in software. The second layer that lies above this is the
luxury vehicles, may have more than approx. 1,000 software func- ECU Abstraction Layer. It establishes die ECU-specif ic hardware lay-
tions, several vehicle electrical networks and more than 70 ECUs. out and provides drivers for the periphery external to the ECU, for
Due to the variety of hardware platforms used in this field, ECU example. In another layer, the Services Layer, var ious basic services
software dependencies on the hardware and system configurations are represented such as network services, memory management,
being used has become problematic. Each change to one of these bus communication services and the operating system. This layer is
constraints requires reprogramming or at least modification of the already largely independent of the hardware. The RTE represents
software. the fourth layer. This is where the actual separation of application
and basic software (BSW) is made. The RTE handles integration of
To make the complexity of ECU software development manageable, the application software and regulates the exchange of data bet-
the AUTOSAR development partnership has defined a practice-test- ween the application and the BSW. It is only at this layer that reuse
ed software architecture that serves as a foundation for developing of already written application software is possible, because the
reusable applications. This open standard for system architecture – defined inter faces make it possible to develop the application soft-
created by automotive OEMs, suppliers and other companies in the ware without special knowledge of the hardware to be used at a
global software, semiconductor and electronics industries – lets later time, and the software can be used for any other AUTOSAR-
users avoid proprietary solutions that would result in increasingly conformant ECUs.
high development cost and effort.
The so-called Vir tual Functional Bus (VFB) forms the basis for con-
AUTOSAR subdivides the electronics architecture into a number of figuration of the layers. All components of the vehicle’s electronics
layers and modules. With the simultaneous def inition of inter faces, communicate in an abstracted view via this bus. The software com-
AUTOSAR creates standards for easy exchange of software compo- ponents use ports for this, whose inter faces can be defined as port
nents or hardware platforms. The development partnership not only inter faces. Connectors connect the ports. It is irrelevant to the VFB
provides specifications for the base software modules. It also offers whether this is a connection within an ECU or a connection via an
a methodology for developing applications and distributed sys- external bus. This is not decided until the final system layout is
tems. This methodology begins with a model-based description of made and specif ic functions are assigned to a specif ic ECU.
the software applications and the distributed system, and ideally
ends in an automatically generated and reproducible test. This for-
mal approach simplifies the use of a universal tool chain.

A full three years after its start, the AUTOSAR development partner-
ship published Release 2.1 at the beginning of 2007. A stable level
was reached with this release, and it has been tested in several vali-
dation projects for its practical utility. At many businesses, the
action item of “AUTOSAR evaluation” has been successfully com-
pleted. Now it is ready to be implemented in concrete production
ECUs.

AUTOSAR Architecture Figure 1:


To realize the objectives of AUTOSAR – separation of the application AUTOSAR layer model for ECU software.
software from basic modules and functions – the vehicle electronics

6/14
39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 2

The software component itself does not require any knowledge of The AUTOSAR Initiative provides universal support for the software
this later distribution, and it can therefore be developed independ- development process by tools. Mature tools are used for structured
ent of it. The component is subdivided into executable units, so- implementation of requirements and their consistent management;
called Runnable Entities, which are executed like procedures when configurations are systematically created, and complex dependen-
a specif ic event occurs. Such an event might be the arrival of a new cies are automatically taken into account.
sensor value or a periodic activation, for example. The description The first step involves formal description of the three primary con-
of the electronic system formulated from the perspective of the VFB stituents: Software (SW Components), ECUs (ECU Resources) and
defines the inter faces of the specif ic software components. As a System Constraints.
result, the application components can be developed independent Suitable editors are used to create a configuration description of
of the specif ic ECU. the complete system (Figure 2). This system configuration serves
The “counterpart” on the ECU is the RTE. It guarantees access to as the basis for the ECU Configurations that the user creates for the
I/Os, memory and other basic services. Using the model-based individual basic software modules with the help of configuration
description, the RTE is generated ECU-specif ically, which means tools. At the end of the process, multiple generators supply the
that it can be adapted to dif ferent requirements while economizing ECU-specif ic implementation of the RTE and basic software.
on resources. All design and configuration data produced in the development
process are described in a uniform format. AUTOSAR has defined an
Methodology XML-based format for this purpose. On the one hand, it guarantees
Besides defining the ECU’s software architecture, the AUTOSAR universality of the development process, and on the other it also
standard also defines a methodology to help in the development of simplifies seamless integration of necessary and auxiliary tools.
AUTOSAR systems. Conformance to a structured creation process is
recognized as an impor tant precondition in creating error-free Migration
software. Deficiencies in the requirements list are detected early, The software architecture of an AUTOSAR ECU is not monolithic,
reuse and porting of software components is simplified, and the rather it consists of a number of standard modules with well-de-
overall system is more reliable. Nonetheless, this methodology also fined inter faces. This enables implementation of migration solu-
allows cer tain freedoms: for example, users can decide whether to tions that offer a risk-free transition to AUTOSAR. Such a migration
use a top-down approach or a bottom-up development. solution must typically be worked out project-specif ically. In prac-

Figure 2:
Structural descrip-
tion of the software
components. The
creation process for
AUTOSAR-conformant
software components
is organized in clear -
ly prescribed devel-
opment steps.

6/15
39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 3

tice, this may involve a mixed configuration of standard AUTOSAR here, which are flexible enough to be used to configure proprietary
modules and proprietary software. basic software too. Non-AUTOSAR modules can now be replaced by
To work out a migration solution, one begins by compar ing the AUTOSAR modules in successive steps, without putting the overall
existing custom software and the AUTOSAR architecture. After an architecture at risk or requir ing reprogramming to other modules.
analysis of overlapping functionalities and integration options, a
decision is made regarding which modules will remain and which Outlook
ones can be replaced by standard software. The current AUTOSAR Release 3.0 represents another step taken to
So, it is advisable, for example, to introduce a separation layer be- enhance the quality of the AUTOSAR standard. The continuing invol-
tween the application and basic software. A potential scenar io in vement of par ticipating companies clearly demonstrates commit-
this case is to prepare the applications as AUTOSAR software com- ment to the goals of the AUTOSAR development partnership. Ideas
ponents already in early migration phase, and to integrate them via are currently being introduced that should become a reality in the
an RTE. Beneath the RTE, a specif ic adaptation layer is used for framework of the future Version 4.0 of the AUTOSAR standard.
inter facing to the existing basic software (Figure 3). New ideas related to AUTOSAR are also being generated by tool sup-
If parts of the existing basic software are to be replaced by AUTOSAR pliers. Current developments at Vector are aimed at making AUTOSAR-
basic software, the emphasis should lie on the use of a uniform based ECU development as convenient and efficient as possible. One
configuration tool for both worlds. Vector offers suitable tools example is a PC-based test tool for AUTOSAR application compo-
nents, which serves as an emulator for the AUTOSAR ECU environ-
ment on the level of the VFB. This makes it easy to test the imple-
mentation code of the AUTOSAR software components on a develop-
ment PC. Widely used standard tools such as Vector’s 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
Figure 3:
use in evaluation projects, and it is production-mature for AUTOSAR
Ear ly introduction of a uniform inter face and RTE
Release 2.0 or 2.1 (3.0 too starting in the 2nd quar ter of 2008).
simplifies migration.

Summary
AUTOSAR is becoming a reality. Var ious OEMs have concrete plans
for implementing AUTOSAR in upcoming vehicle production pro-
grams. 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 descrip-
tion to standardized ECU software.

6/16
39 Press Book_Seite_6-14_6-17:Press Report 4 09.02.2010 13:10 Uhr Seite 4

6/17
AUTOSAR: New Paths to ECU Software – Part 1
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 requirements of different OEMs. This eliminates manual modifica-
vehicles, especially when it comes to communication and diagnos- tion of the software and facilitates its reuse. Defined interfaces
tics. These requirements are implemented in OEM-specific software. make it possible to replace OEM-specific software components (e.g.
If a TIER1 supplies an ECU to several OEMs, it must manually modify for diagnostics) with just minimal effort.
the ECU software for each project. Even if the functional software is
already decoupled quite well from the software, so that it can be AUTOSAR reference architecture
adapted to the OEM-specific requirements, this modification effort
is still work intensive and prone to errors. Figure 1 shows how The AUTOSAR reference architecture is described in the document
unmodified functional software is adapted to different vehicle AUTOSAR Layered Software Architecture [1]. In this document, the
projects without AUTOSAR. ECU software is organized into the three parts shown in Figure 2:
One goal of AUTOSAR is to minimize these adaptation efforts in > The functional software consists of software components (SWCs).
software integration. Therefore, AUTOSAR focuses on consistent The SWCs are created, independent of the ECUs, based on a
abstraction of the software from the hardware and partitioning of Virtual Function Bus (VFB), and they communicate with one
the software into modules with defined functional scope and another via interfaces.
precise interfaces. These modules may be combined and, most sig- > The Runtime Environment (RTE) is used for executing the SWCs and
nificantly, they can be substantially configured to cover the it includes the technical implementation of the VFB in a real ECU.

6/18

40 Press Book_Seite_6-18_6-23.indd 2 09.02.2010 13:27:53 Uhr


> The basic software (BSW) modules handle the basic functions of majority contains functions that were already usually present in
an ECU. They also offer higher-end standard services such as previous software architectures, but now they are more precisely
management of ECU states and diagnostic services. distinguished from one another. Consistent partitioning of func-
tions into individual software modules is what assures the desired
The RTE is the layer between the functional software and the basic hardware abstraction and scalability for different types of ECUs.
software modules. It provides all interfaces the SWCs need to The use of such standard modules increases the quality of the ECU
access data and services of the BSW modules. Examples are signal software. In most cases, this standardization covers the interfaces
values from the communication network (CAN, LIN or FlexRay), I/O as well as functions of the BSW modules. Representing an excep-
signals and standard services of the BSW modules. The interfaces tion here are the BSW modules for diagnostics. Since diagnostic
originate from the “SWC Description” files. Moreover, the RTE han- processes are very dependent on manufacturing and after-sales
dles execution of the SWCs and communication among the SWCs processes at the OEMs, AUTOSAR only defines the interfaces of the
with the help of the operating system. diagnostic modules. This allows OEM-specific implementations of
The BSW modules are subdivided into three layers per the the diagnostic modules. Vector provides these modules for many
AUTOSAR architecture [1]: OEMs, and it is the task of the TIER1 supplier to configure and inte-
> Service Layer grate the specific variant.
> ECU Abstraction Layer Both the BSW modules and the RTE are available as software
> Microcontroller Abstraction Layer (MCAL) products from various software suppliers (TIER2), such as the
MICROSAR products from Vector, which offer coverage of all BSW
The BSW modules of the Service Layer play a special role here, modules and the RTE per AUTOSAR Release 3.0. Although they are
because they contain standard services for the functional software standard software products, the BSW modules and the RTE must be
that are accessed via special interfaces within the RTE. The second adapted to project-specific constraints (OEM, vehicle model, ECU
part of this article, in the next issue, will describe the configura- variant). This involves use of relevant PC-based tools during the
tion of these services in greater detail. configuration process. For example, the RTE may be configured
The AUTOSAR Release 3.0 defines approx. 50 different configu- with DaVinci Developer and the BSW modules with DaVinci Configu-
rable basic software modules; some of them are very complex. The rator Pro from Vector.

Figure 1:
Creating ECU soft-
ware without
AUTOSAR

6/19

40 Press Book_Seite_6-18_6-23.indd 3 09.02.2010 13:27:54 Uhr


AUTOSAR Methodology > Activity: “ECU design and configuration”
Starting with the “ECU Extract of System Descrip-
The AUTOSAR Consortium has defined a method for developing ECU tion”, the TIER1 integrates its own SWCs. This
software, the AUTOSAR Methodology [2]. This document essentially results in a complete and up-to-date “ECU Extract
subdivides the development process into three activities and stan- of System Description”, which now contains the
dardizes data exchange between development partners with a set description of all SWCs (from OEM and TIER1) of
of XML files: an ECU.
Another prerequisite for ECU configuration is the
> Activity: “Component implementation” existence of the “BSW Module Description” files,
The TIER1 or OEM defines the SWCs. For this pur- which contain the definition of the data struc-
pose, it creates an XML file for each SWC, the so- tures and all configurable parameters of a BSW
called “SWC Description”. This file describes the module. These files are implementation-specific
SWC’s interfaces and resource requirements. and – along with the generators and the static
Afterwards, the TIER1 or OEM creates the related code – are part of the BSW modules.
C files for the implementation of the SWC. Afterwards, the TIER1 creates the initial “ECU
Configuration Description” (activity 2 in Figure 3)
> Activity: “System configuration“ based on the current “ECU Extract of System
The OEM first defines the functional scope of the Description”and the “BSW Module Description”
entire vehicle based on the SWCs, independent of files. Then the TIER1 begins to configure the ECU
the ECUs. The next step is to design the communi- and documents it in the “ECU Configuration
cation networks and distribute SWCs to the avail- Description”. The TIER1 uses suitable tools for
able ECUs. The result is saved in the “System configuring and checking parameters of the BSW
Description”. modules and the RTE for this purpose (activities 3
and 4 in Figure 3). The “ECU Configuration
For each ECU, the OEM reduces the “System Description” is the foundation for ECU-specific
Description” to an “ECU Extract of System generation of the RTE and the BSW modules by
Description” which the OEM can pass to the sup- the relevant generators.
plier (TIER1) of the relevant ECU. This file repla-
ces the DBC, FIBEX or LDF files previously used to
configure the BSW modules.

Figure 2:
AUTOSAR architecture of an ECU

6/20

40 Press Book_Seite_6-18_6-23.indd 4 09.02.2010 13:27:54 Uhr


AUTOSAR: NEW PATHS TO ECU SOFTWARE

The AUTOSAR method is flexible and suitable for satisfying the For configuration of the BSW modules, the TIER1 needs the sup-
practical requirements of different projects or different OEMs. For port of a universal tool with user-friendly functions. That is why
example, use of SWCs in the “System Description” is optional. Vector developed DaVinci Configurator Pro. It supports three use
Figure 3 shows – based on the example of the tools DaVinci cases:
Developer and DaVinci Configurator Pro from Vector – how the “ECU > Configuration of MICROSAR BSW modules from Vector
design and configuration” activity can be implemented with tool > Configuration of AUTOSAR BSW modules from third-party
support. manufacturers
> Configuration of software modules you have created yoursel
Configuring and integrating all software components
MICROSAR BSW modules are configured by using a graphical user
During the configuration process defined in AUTOSAR, the TIER1 interface that shows the complex interrelationships of the configu-
selects – from its component collection – those SWCs it needs for ration parameters in simplified form. Furthermore, parameter
the ECU’s functionality. Afterwards the TIER1 integrates them in its selection is limited to valid input values, and this prevents setting
ECU, together with the BSW modules and RTE. This shifts the pri- implausible values.
mary work of integrating the ECU software from manual code adap- The Generic Configuration Editor (GCE) defined in AUTOSAR is
tation to tool supported configuration of the BSW modules and the included with DaVinci Configurator Pro to configure the BSW mod-
RTE. ules from third-party producers. As an alternative, the TIER1 sup-
Since the current level of the AUTOSAR specifications still has plier may choose to develop a user-friendly and integrated configu-
some room for interpretation, from today’s perspective it is advis- ration user interface for these modules itself. This may also be done
able to procure either the entire BSW package, or at least defined with the newly developed DaVinci Configurator Kit. It is used to
BSW clusters, from a single source. The advantage is that the soft- create “BSW Module Description” files for the software modules,
ware supplier (TIER2) can already perform an integration test on define user-friendly user interfaces, establish validation rules and
these modules. However, it is also possible to procure individual create code generators for generating the executable code. The
modules from different TIER2 suppliers or use modified BSW mod- TIER1 can also use this approach to configure its own BSW modules,
ules. This increases integration effort, however, since both func- e.g. complex device drivers.
tional integration and integration in the configuration tools need Both DaVinci Configurator Pro and DaVinci Developer contain vali-
to be performed. dation rules that supplement the AUTOSAR method. They ensure that
Essentially, all MICROSAR BSW modules are tested within system- individual parameters as well as complex parameter groups and their
atic integration tests. As an integration partner, Vector can extend interdependencies are validated and that the “ECU Configuration
its integration services to software modules from thirdparty Description” is generated consistently. This consistency is essential
producers, such as MCAL drivers, upon request. for subsequent generation of the RTE and the BSW modules.

Figure 3:
Tool-supported
integration of
SWCs and configu-
ration of RTE and
BSW modules per
AUTOSAR
methodology

6/21

40 Press Book_Seite_6-18_6-23.indd 5 09.02.2010 13:27:54 Uhr


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

Matthias Wernicke (Dipl.-Ing. (FH))


All Figures: upon graduating in Industrial Electronics at
Vector Informatik GmbH the Polytechnical College at Ulm, was
employed for four years at the Daimler
Literature: Research Center in Ulm, Germany. Since early
[1] Layered Software Architecture: 2000 he has been working at Vector Informa-
http://www.autosar.org/download/specs_aktuell/AUTOSAR_LayeredSoft- tik in Stuttgart, developing methods and
wareArchitecture.pdf tools for the design of distributed electronic
functions in motor vehicles. Today he is
responsible for product management of
[2] AUTOSAR Methodology:
DaVinci AUTOSAR tools.
http://www.autosar.org/download/specs_aktuell/AUTOSAR_Methodology.
pdf Justus Maier (Dipl.-Inf. (FH))
studied Computer Science in Regensburg. He
Links: began his professional career as a developer
Homepage Vector: www.vector.com of standardized software in the insurance
Product information about AUTOSAR: www.autosar-solutions.com 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
>> 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, Göteborg, 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

40 Press Book_Seite_6-18_6-23.indd 6 09.02.2010 13:27:55 Uhr


6/23

40 Press Book_Seite_6-18_6-23.indd 7 09.02.2010 13:27:56 Uhr


AUTOSAR: New Paths to ECU Software – Part 2
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 New development of software components (SWCs)
used to adapt the basic software (BSW) and runtime environment
(RTE) to specific ECU requirements. Generation is based on the fol- Depending on the OEM, the “ECU Extract of System Description”
lowing extensive description files mentioned in the first part of the might already contain the interfaces of SWCs. In some cases, these
article: SWCs are still incomplete. For example, OEM-specified application
> The “ECU Extract of System Description” contains the ECU- interfaces may be included, but not the implementation descrip-
specific section of the overall system. tion (runnable entities) or interfaces to the standard services of
> The “SWC Description” describes the interfaces and structure of the BSW modules. The Tier1 developer can add this missing specifi-
the AUTOSAR software components (SWCs), and it may already cation with the help of a tool such as DaVinci Developer. The Tier1
be included in the “ECU Extract of System Description”. may also create its own SWCs (Step D1 in Figure 4).
> The “ECU Configuration Description” contains the configuration There are two different ways to implement the SWCs: either man-
of the BSW modules and RTE. ually based on a generated code template or with the help of mod-
> The “BSW Module Description” describes the configurable el-based development (MBD) tools such as MATLAB®/Simulink®
parameters of a BSW module. EmbeddedCoder® or TargetLink. The “SWC Description” is imported
into the MBD tool where it serves as a basis for modeling the SWC.
The challenge for the developer is to keep these description files Code generators are used to automatically generate SWC
consistent while avoiding the need to recreate the whole configu- implementations.
ration whenever a change is made. In performing this task, it is If SWCs are already available at the Tier1, they can also be inte-
helpful to use configuration tools that support iterative work pro- grated in the ECU. This involves importing the relevant “SWC
cesses during an ECU development project. Typical scenarios and Description” and linking the SWC to the other SWCs of the ECU
change cases are described as well as having work steps explained (Step D2).
based on the Vector tools DaVinci Developer and DaVinci Configura-
tor Pro.

Figure 4:
Development of
functional soft-
ware consisting of
multiple SWCs

6/24

41 Press Book_Seite_6-24_6-27.indd 2 09.02.2010 13:27:36 Uhr


In a separate integration step, data elements of the SWC inter- Component. This SWC can also be created by a “top-down” or “bot-
faces are assigned to bus signals (data mapping) – provided that tom-up” approach.
the OEM has not already defined such a mapping in the “ECU Extract At the end of the integration process, the Tier1 gets an updated
of System Description”. “ECU Extract of System Description”. Besides the OEM’s original
Typically, the “ECU Extract of System Description” will change a version, the file now also contains content defined by the Tier1 and
number of times over the course of a project. When the Tier1 is fully validated.
receives a new version, the SWCs it contains might also be modi-
fied. A special Update function makes it possible to accept changes Modification of the RTE after changing SWCs
in DaVinci Developer without losing any extensions previously
made by the Tier1, such as implementation descriptions or inter- If only the implementation of a SWC changes without affecting the
faces to standard services. SWC’s interfaces or structure, neither the RTE nor the basic soft-
ware would need to be reconfigured. However, if the structure of a
Configuration of standard AUTOSAR services SWC changes, e.g. due to the addition of a new runnable entity, the
RTE configuration must be modified. This involves assigning the
One challenge arising in the configuration of AUTOSAR ECUs is how newly added runnable entity to a task. After this modification has
to configure the standard services of the BSW modules. Within the been made (Step D4 in Figure 5), the RTE configuration is validated
“ECU Extract of System Configuration”, the services are represent- (Step D5).
ed by special SWCs, the so-called service components. These service The DaVinci Developer supports this process with detailed error
components are created and integrated with the SWCs by what is messages and recommended corrections. For example, inconsisten-
referred to as Service Mapping, which can be performed automati- cies are reported so that the Tier1 can correct the “SWC Descrip-
cally with tool support (Step D3). tion” or RTE configuration.
In the “top-down” approach, the need for services is determined
from the entire functional software, and the services of the BSW Incorporating changed communication data from the OEM
modules are configured accordingly. This approach makes sense for
those services that are not typically specified by the OEM in detail. A typical change scenario is updating the communication data of
Examples are services of the NVM (Non-Volatile Memory Manager) an ECU, e.g. because the distribution of signals to messages has
or the ECUM (ECU Manager). changed. Such a change is only relevant to those BSW modules
In the “bottom-up” method, the service is first configured in the related to communication and does not require any changes to the
BSW module, e.g. based on OEM requirements. The SWCs are then RTE or SWCs.
extended to match the service configuration. An example of this is Figure 6 shows the work steps that are performed to accept the
the DCM (Diagnostic Communication Manager). changed communication data. The BSW modules can be adapted
Just like the services, the ECU’s I/O interfaces are also repre- automatically: First, a new “ECU Configuration Description” is gen-
sented by a special SWC – the I/O Hardware Abstraction erated, and the contents of the old “ECU Configuration Description”

Figure 5:
Work steps in con-
figuring the RTE

6/25

41 Press Book_Seite_6-24_6-27.indd 3 09.02.2010 13:27:36 Uhr


are converted to the new “ECU Configuration Description” (Step processors or own BSW modules. This is enabled by the DaVinci
C1-2). All parameter values unaffected by the change are automati- Configurator Kit, which is used to create the Tier1 BSWMD files and
cally accepted. Only the parameters of the new or modified signals module interface files. They contain definitions of specific configu-
or messages are then configured in Step C3. Finally, to ensure that ration interfaces, validation rules or generators for the BSW mod-
all parameter values are consistent, the new “ECU Configuration ules (Steps C5 and C6).
Description” is validated in Step C4.
As a supplement to the AUTOSAR standard, Vector has imple- Replacing OEM-specific diagnostics
mented an “Update” function and validation in DaVinci Configura-
tor Pro. If the OEM does not provide an AUTOSAR-conformant ECU If an existing ECU configuration is to be used for a different OEM,
Extract of the System Description, the Tier1 can instead use the the ECU’s diagnostic basic software must be replaced, because it is
familiar network description formats (DBC, LDF or FIBEX) as inputs OEM-specific. This affects the DCM and DEM (Diagnostic Event Man-
to the DaVinci tools. ager) BSW modules.
Figure 7 shows how this replacement is made. The Tier1 obtains
Switching over to a different processor or processor type the new CDD or ODX file from the OEM. These widely used formats
contain the diagnostic description data for the ECU. They can be
Thanks to the systematic hardware abstraction offered by AUTOSAR generated with tools such as CANdelaStudio from Vector. DaVinci
the TIER1 only needs to replace the affected MCAL modules when Configurator Pro utilizes information from these files to automati-
switching over to a different processor device or processor type. cally configure diagnostic BSW modules for the ECU (Step C7).
This transition is performed with tool support: The old MCAL mod- Analogous to the modified diagnostic BSW modules, the DCM and
ules are removed and the new MCAL modules are added to the pro- DEM service components must also be modified and made known to
ject by selecting the new BSWMD files. The new platform-depen- the application SWCs in a “bottom-up” process. For this purpose,
dent parameter values that were added are checked in DaVinci Con- DaVinci Configurator Pro takes the “ECU Configuration Description”
figurator Pro and reconfigured by the Tier1 as necessary (Step C3 and generates the “SWC description” files which include service
for each changed MCAL module). Consistency of the “ECU Configu- components for DCM and DEM (Step C8).
ration Description” is restored by final validation (Step C4). The Tier1 can now use DaVinci Developer to generate the service
Especially useful to the Tier1 is the ability to extend the tool mapping for all diagnostic services of the new OEM. Validation of
environment, e.g. to support the MCAL modules of future the SWCs ensures that no service is forgotten in the change

Figure 6:
Work steps in
configuring the
basic software

6/26

41 Press Book_Seite_6-24_6-27.indd 4 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 representa-
tion 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 pre-
vents 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
diagnostic-
specific software
parts of an ECU

6/27

41 Press Book_Seite_6-24_6-27.indd 5 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 Soci- scheme. Despite all of its standardization aspects, J1939 gives
ety of Automotive Engineers (SAE) – serves above all to preserve a OEMs sufficient freedom for customized extension of communica-
uniform perspective and uniform handling of the most common tion. This is especially important in promoting innovations,
vehicle components of various vehicle types and manufacturers. In because no OEM wants to announce or discuss plans in working
this context, it is interesting to note certain distinct differences committees before their implementation.
between the European and North-American heavy-duty vehicle
markets. For example, heavy-duty vehicle buyers in the USA have ISO Layers Model decouples the Application from
prescribed to OEMs which components they need to install in spe- Transmission Physics
cific vehicles. In Europe, on the other hand, it is the OEMs who fully
define the design of the entire vehicle, including the components From the perspective of the ISO/OSI network model, J1939 is
and their configuration. essentially based on the Application Layer (Layer 7), Network Layer
Besides using uniformly defined signals and data formats to (Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1)
communicate, it is of course important that receivers know how to (Figure 1). This lets developers work with signals without needing
interpret the information. Ideally, it should be possible to inter- to be concerned about communication details on the Application
connect individual J1939 components based on a plug-and-play Level, such as details of the transport protocols. J1939

7/0

42 Press Book_Seite_7-00_7-05.indd 2 09.02.2010 13:25:30 Uhr


Figure 1:
The J1939 protocol essentially cov-
ers 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 work-
ing on the application level.

documentation and definition is oriented toward individual layers, (PGN) – also contains the J1939 ECU address of the sender and if
and this is expressed in the names of the total of 14 documents of applicable the address of the receiver too. In addition, the three
the standard. For example, documents of the 7 series such as most significant bits of the CAN identifier are reserved for the pri-
“J1939/71” refer to the Applications Layer, document J1939/21 ority field; although these bits do not replace the implicit priority
the Data Link Layer, etc. established by the CAN protocol, they make it possible to organize
the Parameter Groups into up to eight J1939-specific priority lev-
CAN Message Format in J1939 els. These priorities are used to adjust the priority to momentary
application requirements at the time the Parameter Group is trans-
Although J1939 utilizes normal 29-bit CAN messages with up to 8 mitted – or during an optional ECU configuration phase. This makes
bytes of data, here the CAN identifier quasi defines the mask of a it possible to fine-tune communication to the application without
uniform J1939 scheme (Figure 2). This is necessary to assure plug- the SAE protocol permanently setting the priority when the Param-
and-play properties. The CAN identifier – besides identifying the eter Group is defined.
useful data with the help of the Parameter Group Number

Figure 2:
The J1939 message format – which
is based on normal 29-bit CAN
messages – requires some supple-
mentation to achieve plug-and-play
capability. The CAN identifier quasi
defines the mask of a uniform J1939
scheme.

7/1

42 Press Book_Seite_7-00_7-05.indd 3 09.02.2010 13:25:31 Uhr


The Name says it all: J1939 Device Names address; they are used for device configuration or ECU commands,
for example. Broadcast messages (1:n), on the other hand, are
J1939 defines device names that are each represented by a 64-bit simultaneously addressed to all bus nodes, which is practical when
number. When an ECU is switched to active in the plug-and-play it comes to sending out measured values, error handling and diag-
network, the device name serves to identify the device and its func- nostic purposes.
tionality. The device name is subdivided into different elements,
between which certain dependencies exist. The independent fields Flexible Network Topology
include the Industry Group and Manufacturer Code. The Industry
Group is used to establish the functions required in the network, J1939 works with a passive bus that is terminated at each of its two
since the J1939 protocol is not only used in conventional heavy- ends with 120 Ohm impedance. The advantage here is that individ-
duty vehicles but also in vehicles in the agricultural and marine ual ECUs can be connected to the bus via branch lines with a length
industries. Each ECU carries one of the SAE assigned Manufacturer of 1 to 3 m. This enables flexible wire harness design, provided that
Codes that can be requested from that organization. Since each a total bus length of 40 m is not exceeded. Depending on the physi-
device also has a serial number, the complete name over all fields is cal transmission layer, between 10 and a maximum of 30 nodes may
unique worldwide, and there are no overlaps. be connected to the network. J1939 provides uniform diagnostic
Since addressability of the devices is inefficient in practice when access for service testers and on-board diagnostics. Legal require-
64 bit long device names are used, the SAE defines 8-bit addresses ments specify that a branch line with a length of up to 5 m must be
for the individual vehicle components in the heavy-duty vehicle possible here, e.g. for road tests of the emissions control system.
field; practically these addresses never change over the life of the Bridges can be used to extend J1939 networks to include trailers/
components. This does not apply to the agricultural and marine implements, enabling implementation of a separate network there
industries; there the addresses are dynamically negotiated at the (Figure 3). In the EU, ISO 11992 has prevailed for this purpose,
start, based on the device name. The addresses 0 to 127 are while in the USA the “Power Line Carrier” is state-of-the-art
assigned to the most commonly used ECUs such as engine, trans- technology.
mission, retarder, brakes, etc., while the range from 128 to 247 is
reserved for agricultural, marine, construction equipment, etc. Timing Requirements in ECU Design
Service tools, OBD scanners, etc. occupy addresses from 248 to
253. Finally, there are the special addresses: 254 to identify devices In designing J1939 ECUs, care should be taken to ensure that no
that do not have their own address and 255 that is used as a global messages are lost due to hardware or design limitations. At a
address for addressing broadcast messages. baudrate of 250 Kbps, transmission of one bit takes 4 microsec-
onds. With 8 data bytes, a typical message length of about 128 bits
Types of Communication: Point-to-Point or Broadcast is obtained, yielding a transmission time of about 500 microsec-
onds per CAN message. The shortest message length, however, is
The J1939 protocol supports two communication types: point-to- 64 bits, i.e. it must be possible to receive messages at intervals of
point transmissions (1:1) are directed to precisely one target 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

42 Press Book_Seite_7-00_7-05.indd 4 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 controller’s often A J1939 extension is available for the widely used CANoe devel-
limited CAN identifier filtering capabilities. Filtering also usually opment and test tool; it spares heavy-duty vehicle developers from
needs to be implemented in software. needing to train in the details of the J1939 protocol. The package
from Vector extends basic software functionality to cover all neces-
Testing and Diagnostics of J1939 Components and sary protocol-specific features. When CANoe.J1939 is used consis-
Systems tently, the models and databases created in the design phase not
only serve as a foundation for simulation during development, but
In view of the rising number of J1939 ECUs and the fact that soft- also for all tests accompanying development up to and including
ware solutions in heavy-duty vehicles are becoming increasingly later diagnostic tasks (Figure 4). With the help of simulated nodes,
complex, a systematic strategy for testing and diagnostics also it is possible to set up and execute tests for the ECU to be devel-
continues to gain in importance in the J1939 field. Tests are indis- oped. The tests are further refined during development and are
pensable in all development phases, from functional tests to inte- used in verification of the total system.
gration tests to driving trials in the total vehicle. It is well known
that the later that errors are detected, the more complicated and Extensive J1939 Test Library
expensive it is to correct them. However, it is generally only possi-
ble to test ECUs comprehensively after they have been integrated The CANoe Test Feature Set is made up of CAPL test modules, XML
in the network structure. Consequently, weak points are often not test modules and .NET test modules. They are able to cover all chal-
revealed until very late, unless one relies on the support of proven lenges arising in testing tasks of varying complexity, from simple
software tools right from the start. to difficult test cases. While the C-like script language CAPL is ideal
Given this situation, the use of specialized tools offers develop- for creating extensive test scenarios, the primary focus of XML is
ers substantial simplifications in testing and diagnostic tasks. For on simple parameterization of test patterns and simple generation
many years now, Vector has been actively involved in SAE J1939 of test procedures. That makes it possible to implement applica-
subcommittees and regularly participates in working sessions. With tion-specific test modules (function libraries) in CAPL and then
a universal tool chain for all J1939 projects, it is possible to effi- generate test control that is individually adapted to the ECU con-
ciently solve the most challenging tasks in networking and commu- figuration. The J1939-specific extensions in the Test Service
nication in the heavy-duty vehicle field [1]. Besides development, Libraries allow the system react to Parameter Groups (PG) instead
testing and analysis tools, embedded software components tai- of typical CAN identifiers. They also offer test patterns for J1939
lored to the special requirements of J1939-based applications are protocol functionality and checks (background monitoring) for
available, and customized project work and training events round protocol violations. For example, it is possible to test whether the
out Vector’s products and services. 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 cor-
rect errors early on in all develop-
ment phases. The CANoe Test Feature
Set offers extensive testing and
analysis capabilities.

7/3

42 Press Book_Seite_7-00_7-05.indd 5 09.02.2010 13:25:32 Uhr


time under high bus load. Furthermore, it is possible to send faulty and are implemented step-by-step on the final target hardware
transmissions via the BAM (Broadcast Announce Message) and platform. CANoe.J1939 can also integrate Matlab/Simulink models
CMDT (Connection Mode Data Transfer) transport protocols for test in ECU and network simulations (Figure 5). With the Real-Time
purposes. Workshop from Mathworks the user generates a *.DLL for CANoe so
To create the test modules – besides the J1939 Test Module Man- that variable names and units are compatible.
ager and the convenient Test Automation Editor – the Option DiVa Progressing through the various stages of the V development
is useful. DiVa creates a connection between CANoe and the diag- model, individual tests and subsystem tests are possible through
nostic specification tool CANdelaStudio, so that specifications cre- final verification of the overall system. This enables early detection
ated there can be ideally used in further ECU-specific diagnostic and correction of errors. If an error is found, the automated tests
tests. can be restarted at any time; they minimize the risk of side effects
Other functions of the Test Feature Set relate to test flow control in error correction. As a result, development is characterized by
and automatic report generation, including statistical information short verification cycles, enabling a seamless transition from MIL
in XML or HTML format based to individual requirements. Further (Model in the loop) to SIL (Software in the loop) and then to the
options for automating test processes are enabled by the COM real ECU (HIL – Hardware in the loop). If there are exceptional real-
interface, e.g. options relating to flow control, parameter changes time requirements of the simulation platform, a special real-time
or status queries. CANoe Option J1939 provides a trace window, version is available with CANoe RT.
J1939 diagnostic monitor and J1939 diagnostic memory access for
diagnostic purposes. The diagnostic monitor supports various Realizing Goals quickly with standardized Embedded
J1939 diagnostic messages, such as DM1 and DM2, and it serves to Software Components
display and clear active errors. Also possible is access to memory
areas, objects and parameters as well as periodic object updating Use of CANbedded J1939 software components leads to quick
for monitoring purposes. development results. These components largely relieve developers
of the need to handle all of the details of the J1939 standard, and
Integrating Matlab/Simulink Models in J1939 Network they avoid duplicated developments. A key aspect is a central OEM-
Simulations managed database containing all elementary information related
to ECU communication. Depending on requirements, this informa-
Generally, various function models are created for mechanical com- tion might be distributed to other working partners, producing
ponents such as transmission, powertrain or even the entire vehicle flexible distribution of tasks between the OEM, network specialists
during the different heavy-duty vehicle development phases. ECU from Vector and suppliers (Figure 6). The latter can use the GENy
architectures are initially saved in virtual CANoe function models 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 inte-
grate 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

42 Press Book_Seite_7-00_7-05.indd 6 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 test-
Peter Fellmeth
ing, compatibility on the CAN bus based on unambiguous signal studied at the University of Applied Sciences
interpretation and maximum quality and flexibility in the J1939 in Esslingen, Germany, majoring in Computer
communication stack. CANbedded J1939 supports all relevant Engineering and specializing in Automation
Technology. He is team leader and product
microcontrollers and is characterized by low ROM and RAM memory manager at Vector Informatik GmbH, where
requirements as well as high runtime efficiency. he is responsible for the development of
products and customer-specific projects
related to J1939, ISOBUS, Ethernet and
DeviceNet.
Internet links:
[1] J1939 solutions from Vector – www.j1939-solutions.com
[2] Download of presentations from J1939 User Day – Thomas Löffler
www.vector-worldwide.com/ud [most of them are German] studied Automation Technology at the Uni-
versity 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 develop-
ments and enables optimal work
distribution.

7/5

42 Press Book_Seite_7-00_7-05.indd 7 09.02.2010 13:25:32 Uhr


43 Press Book_Seite_7-06_7-13:Press Report 1 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 ticipat-
ed 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 moun-
tain stations or injured per-
sons safely down to the val-
ley. They not only embody a
special species of all-ter-
rain 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 functionali-
ty 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 develop-
ment tools of the latest generation of PistenBully vehicles from the Kässbohrer Company.

In contrast to conventional off-road vehicles, the technical in the cockpit display also provides optimal visibility when
challenge for the PistenBully is to master the numerous ex- driving in reverse. To support grooming on steep inclines the
treme situations encountered in cold, snow and nighttime vehicles can be optionally equipped with electro-hydraulic
operation. The machine, capable of moving in any direction cable drums that carry 1,000 m of cable. A special feature is
on inclines up to 45°, covers an area of 96,000 m2/h with its free rotation of the drum, allowing the vehicle to turn 360°
multiflex tiller. This technology is standard equipment for as of ten as desired. Besides models for use on mountains
duties up to 4,000 m above mean sea level and extreme out- and snow, there are also PistenBully versions without a load-
side temperatures; the elevation capability of the polar ver-
sion even reaches up to 6,000 m.

Greatest Safety under Extreme Conditions


Slope grooming is of ten scheduled for evening and night-
time hours, while there are no regular winter sports activi-
ties. 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 re-
duce 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 Figure 1:
driver from rock impacts, and a lighting system with a wide Up to 620 PistenBullys are produced in Laupheim every
array of running lights, searchlights and working lights turn year
night into day. Automatic integration of a rear camera image

7/6
43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/7

ing platform, versions exclusively used to transport person- starting up from a stop and prevents adverse events such as
nel, excavating versions and even versions that can swim. stalling. Simultaneously, load limit control of fers protection
Kässbohrer produces about 600 to 620 units per year, and against overloading and over revving of the diesel engine.
the cost per vehicle lies between 80,000 and 340,000 euros.
A single gas pedal is used to accelerate and decelerate (brak-
Power for Driving, For Ski Lifts and Emergency ing), i.e. there is no working brake, only a parking brake.
Electrical Generators Changes in driving direction are achieved by dif ferential
The vehicles are driven by engines from Mercedes-Benz with track speeds. Each drive has infinitely var iable output speed
power ratings between 90 HP and 460 HP. The latest Pisten- adjustment and its direction of rotation can be reversed. As a
Bully 600 has a standard 12.8 Liter engine deliver ing 295 kW result, the fully electronic steer ing can support turning in
(400 HP) and torques of up to 1,900 Nm. Two independent place, pre-selection of driving direction and speed reduc-
hydrostatic drive circuits without separate clutches are re- tion. The “steer ing aggressiveness” varies with driving
sponsible for tractive power to the right and left sides. The speed; the driver can adjust it to his or hers specif ic needs.
engine controller delivers the required engine torque when 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
43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/8

pedal or load limit control without af fecting the turning ra- are reserved for future functions not currently needed, and
dius. Wheel sensors enable straight-line and uniform curve they are technically ready to implement them. Additionally,
control or asymmetrical steer ing character istics for special CAN is utilized for software updates, parameter configura-
applications. tion and in measurement systems. Since all functions can
currently be implemented with CAN, the use of newer com-
Nothing runs without vehicle electronics munication systems such as FlexRay, LIN or MOST is not cur-
Electronics is or at least was of ten considered a necessary rently under discussion. The electrical system is set up to be
evil by conventional machine building companies. The Käss- fully modular and is uniform across all vehicle var iants. Since
bohrer Company, whose or igins are in the steel building in- the basic wir ing already considers all current and future op-
dustry, has come full circle in its perspective here. Without tions, it is easy to accomplish expansions and retrof its by
electronics any meaningful interplay between complex vehi- means of adapter wire harnesses.
cle components would be inconceivable. Vehicle electronics
is ever present, from steer ing, control of the engine and hy- Lots of power electronics, just a few fuses and
draulic system, conveniences of vehicle navigation and the no relays
control of implements, to functions for operational data ac- The PistenBully universal PSX control module is responsible
quisition, telematics and GPS. for central control of all functions such as per formance and
Consistent and thorough networking of the vehicle by CAN power management, engine control, hydraulics of the drive
(Controller Area Network) was a prerequisite for achieving a and tilling pumps, oil flow distribution of the working hy-
decentralized control structure. This made it possible to ra- draulics, front and rear, as well as monitor ing of all sensors
tionally combine electronic and mechanical components to and actuators. It is supplemented by the “central electron-
make one control module. In compar ison to earlier Pisten- ics” unit, which besides of fer ing numerous diagnostically ca-
Bully generations, decentralization has enabled signif icant pable and short-circuit protected inputs/outputs, also hous-
reductions in wir ing costs. Nearly all communication is rout- es other functionality such as central locking, RF remote
ed over the two primary buses CAN1 and CAN2 (of a total of control, lighting control and voltage converters for 12 V. The
five CAN bus lines). While CAN3 is used for external commu- full load capable unit supplies a summed continuous current
nications in fleet management, the CAN4 and CAN5 systems 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 “ac-
tual” 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 con-
trols and display elements of the cockpit. In addition to the
ergonomic semi-circular steer ing wheel, also includes a mul-
tifunction 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: The multifunction display gives momentary information at a


Controls and display components in the PistenBully cockpit glance on the most impor tant operating states and on driv-
ing speed, cable drum tension, engine data, etc. It of fers in-

7/8
43 Press Book_Seite_7-06_7-13:Press Report 1 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
43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/10

tuitive control, on the touchscreen or via the TCC. The oper- 20 mA current inter faces to automatically compensate for
ating panel mounted to the right of the driver with its film contact resistances when electrical connections corrode.
keypad lets the user select numerous Pistenbully functions While Kässbohrer utilizes its internal KGF protocol for the
directly. A joystick is used to control the var ious movements CAN1 functional bus, the J1939 protocol is used on CAN2 for
of the snow blade and of the rear implement carrier as well the drive system. The advantage of standardized drive man-
as used to set the tilling pressure, cable drum tension, etc. agement based on SAE J1939 is that the drive system can be
The joystick is an in-house development, since none of the built with components from outside suppliers, independent
commercially available models could satisfy the expectations of the vehicle producer, including a suitable diagnostic sys-
of Pistenbully developers. tem. On the functional side, the proprietary protocol was
used intentionally to prevent unauthor ized manipulations
CAN controls hydraulic module and simultaneously to protect know-how. That is why it was
CAN2 serves as a sensor-actuator bus for engine control and also decided not to use the CCP (CAN Calibration Protocol)
valve control and an inter face for sensors. The hydraulic val- standard for the ECU application. The CAN bus systems can
ves are driven entirely via CAN, i.e. without supplemental be parameter ized and diagnosed from a laptop.
analog or digital I/O signals. On the part of the sensor/actu-
ator bus, so-called multi-modules provide input channels, Safe return to the valley even if the bus fails
digital outputs, PWM outputs and bridge outputs that are di- It is interesting that X-by-wire systems have already been
agnostically capable, short-circuit protected and self-heal- used in PistenBully production vehicles since the 1970s, whi-
ing. The sensors connected here are all equipped with 4 to le its implementation in general road vehicles was not even a

Figure 6:
CANoe in measure-
ment data acquisi-
tion dur ing vehicle
trials

7/10
43 Press Book_Seite_7-06_7-13:Press Report 1 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 developers on a project like the PistenBully must rely on
legal regulations apply to the operation and safety of pure power ful tools for software development too. Over the cour-
off-road vehicles not subject to highway vehicle registration, se of the development process it is essential to per form
since the vehicles are used exclusively on private land. If design functions, tests and simulations of subsystems and
there is failure of the steer ing potentiometer, driving direc- overall systems. This is where CANoe with the J1939 Option
tion pushbuttons and/or the redundant gas pedal with a from Vector comes into play.
contact less sensor, driving capability is preserved as long as CANoe’s capabilities as a development and simulation tool
possible. The vehicle, weighing in at between 7 and 10 met- range from simulation of a single network node, to testing
ric tons and capable of a maximum speed of 23 km/h, can and diagnostics, to representation of complete CAN net-
then be driven safely back to the valley with emergency run- works. Beginning with initial studies on the purely vir tual
ning character istics at a throttled-down speed of 5 km/h. model, the vir tual nodes can gradually be replaced by real
Even if both CAN buses fail the PistenBully remains maneu- hardware step-by-step over the fur ther course of develop-
verable with control via PWM signals. ment. In this case, vehicle functions are executed by a vir tu-
For the electronics, besides satisfying requirements for harsh al ECU in an OSEK emulation. Among other things, this
temperature and humidity conditions and mechanical stress- makes it possible to control and display the states of vir tual
es, other special requirements also apply, e.g. with regard to sensors and actuators. It is also possible to generate associ-
electromagnetic compatibility. This ensures that the high ated control panels automatically.
field strengths of radio transmitters on mountain peaks will
never impair vehicle functions. Short development times
At Kässbohrer some of the uses of CANoe are to simulate bus
From simulation to real PistenBully electronics loads, function as a measurement tool and parameter ize
Software development and vehicle calibration cover ing all ECUs by the proprietary KGF Protocol. The developers use
control modules are all per formed at the Kässbohrer Compa- this protocol to generate diagnostic and setup information
ny. This lets the producer from Laupheim adapt flexibly to in temperature tests, EMC tests and reaction tests of valve
new operating situations. Since the complexity of the soft- controls, for example, and this helps them to keep solutions
ware and the electronic functions is constantly growing, for production vehicles lean.

Figure 7: Easy fault localization for the driver with OBD

7/11
43 Press Book_Seite_7-06_7-13:Press Report 1 09.02.2010 13:09 Uhr Seite 8/12

The development of dual-channel fan control in the Pisten- gramming PC that is connected to the CAN diagnostic con-
Bully was completed in an exceptionally short time without nector. For every PistenBully there is an electronic vehicle
utilizing real hydraulic pumps, valves or motors. In such cas- record that seamlessly documents software updates, the life
es CANoe realistically simulates all necessary CAN nodes, of individual components, current software levels, etc. It is
sensor signals and ECU information. In ECU setup CANoe en- possible to restore the delivered state at any time. If prob-
ables access to EEPROM contents via an in-house flash proto- lems occur at the customer, On-Board Diagnostics of fers fast
col. This is easy to reprogram with the integrated program- and convenient fault localization over the cockpit display. All
ming language CAPL (Communication Access Programming hydraulic functions, sensors and actuators are designed to
Language). The EEPROM data stored on the hard drive can be be electronically diagnosable. All that is needed for in-vehi-
loaded into the controller at any time. cle troubleshooting is a circuit diagram and the display; no
other equipment is needed. Stored in the fault memory are
Indispensable: Real-time capability of develop- the error history and error frequencies.
ment tools
An employee explains: “As developers we rely on good tools, All figures: Kässbohrer Geländefahrzeug AG
and CANoe’s reliability is excellent! Real-time capability is
especially impor tant to us. We have already had negative ex-
periences with similar software on another project. It took Authors:

days of troubleshooting to finally find out that the tool sim- Thomas Böck (Graduate Engineer) studied general
ply could not keep pace with our sampling rate requirements, electrical engineer ing at the technical college in
and this led to erroneous results.” Kempten, Germany. He manages development in
the electronics/hydraulics area.
In-house user inter faces, panels and other tools that are fre- Tel. 07392/900-254, Fax 07392/900-259,
quently needed are generally programmed in-house at Käss- E-mail: thomas.boeck@pistenbully.com
bohrer using Borland C++. Even in such custom develop-
ments CANoe databases always serve as the foundation.
Moreover, CANoe facilitates optimal cooperation with suppli- Peter Betz (Graduate Engineer) studied telecom-
munication engineer ing at the technical college in
ers since the behavior of assemblies can be tested in ad- Ulm, Germany. He is responsible for system devel-
vance. The PistenBully developers only regret that not all opment in the electronics development area.
Tel. 07392/900-262, Fax 07392/900-259,
system suppliers provide CANoe simulations of their pro- E-mail: peter.betz@pistenbully.com
ducts or make them available early on.

Mobility for fine tuning on the slopes Markus Hörmann (Graduate Engineer) studied tel-
Another impor tant aspect is tool mobility. Since snow condi- ecommunication engineer ing at the technical col-
lege in Kempten, Germany. He manages test equip-<