Master Thesis Ketan Bavalia

Technische Universitt Chemnitz
Faculty of Computer Science
Master Thesis
CONCEPT AND IMPLEMENTATION OF A UNIVERSAL

UDS API FOR MODULAR USE IN TEST
ENVIRONMENTS FOR VEHICLE COMMUNICATION
TESTS
Masters of Science in Automotive Software Engineering
Prof. Dr. Wolfram Hardt
Dr. Ariane Heller
Professor
Professor
Supervisor 1
Supervisor 2
MSc. Stefan Bogner

Supervisor at Bertrandt Ingenieurbro GmbH
Declaration
I declare that I have prepared the master thesis "Concept and implementation of a universal
UDS API for modular use in test environments for vehicle communication tests" without
illegal help. I also declare that contributions by other authors which are used in the thesis
or led to the ideas behind the thesis are properly referenced in written form.
By respecting the data protection policy of Bertrandt Ingenieurbro GmbH, no confidential
content of Bertrandt Ingenieurbro GmbH is being used in this thesis work.
I am aware that a master thesis, developed under guidance, is part of the examination and
may not be commercially used or transferred to a third party.
Ingolstadt, June 11, 2015
Ketan Bavalia
Lock Flag
This master thesis contains confidential information and data. Publication, release or duplication in parts or in the whole without the written consent of the company is not permitted.
Furthermore, disclosure of the information to anyone other than the examination board or
editors is not authorized.
Ketan Bavalia
Ingolstadt, June 11, 2015
Acknowledgement
First of all, I am grateful to my Guru Pramukh Swami Maharaj for everything good happen
in my life. I would like to express my gratitude to my Prof. Dr. Wolfram Hardt and Dr.
Ariane Heller from Technische Universitt Chemnitz for the support and guidance on the
way of master thesis.
I consider it an honour to work with Mr. Stefan Bogner from Bertrandt AG, who has
introduced me to the topic. It is with immense gratitude that I acknowledge his support,
help, useful comments, remarks and engagement through the learning process of this master
thesis.
I am indebted to many colleagues and friends who have technically supported me with new
ideas and suggestions to make my work better. A special thanks to Mr. Marc Schilhaneck.
I thank Mr. Christian Gehrke for sharing insights of his work which was related to my
research work.
I would like to thank my loved ones and my parents, who have supported me throughout
entire process by keeping me passionate for my goal. I will be grateful for their love and
blessings.
Thank you.
Abstract
The networking of control devices is well advanced in a modern automobile. To ensure
secure communications with each other and to prevent mistakes due to communication error,
protocol tests are performed at the physical and data link layer level. In a modern car the
diagnosis of the electronic devices (e.g. reading/deleting fault memory entries) is done with a
standardized communication protocol (UDS - Unified Diagnostic Services). Modern control
units have this diagnostic capabilities to detect this communication error among others.
This data is provided for a guided troubleshooting the vehicle via a defined interface. In this
communication test detection mechanisms are specifically stimulated and read afterwards.
In order to read or delete these entries, a diagnosis query is performed on the basis of the
diagnostic protocol UDS.
The diagnostic requests are currently performed with a diagnostic service of bus analysis
software Vector CANoe. This service requests can be performed directly on CAN but for
the diagnosis of other bus systems a software gateway is used. The maintenance required and
the error rate of the software gateways is very high and should be replaced in the future.
Furthermore, additional bus systems can be integrated only with great effort. Therfore
the main aim of the master thesis was to develop a concept for univesal UDS API and
afterwards implementation of that concept using CAPL programming for modular use in
test environments for vehicle communication testing.
Contents
Abstract
iv
1 Introduction
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Structure of master thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
2 Basics
2.1 Vehicle networking . . . . . . . . . . . . .
2.1.1 CAN Control Area Network . . . .
2.1.2 ISO-Transport Protocol . . . . . .
2.1.3 FlexRay . . . . . . . . . . . . . . .
2.1.4 FlexRay TP . . . . . . . . . . . . .
2.2 Diagnostic . . . . . . . . . . . . . . . . . .
2.2.1 Overview on automotive diagnosis
2.2.2 UDS Protocol . . . . . . . . . . . .
2.2.3 UDS Services . . . . . . . . . . . .
2.2.4 Open Diagnostic Data Exchange .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 State of the art

4 Concept
4.1 Modification of the ISO/OSI model
4.2 System Requirements . . . . . . . .
4.3 Modular design of the API . . . . .
4.4 Concept realization . . . . . . . . .
5
5
6
9
13
16
18
18
20
22
26
28
.
.
.
.
5 Implementation
5.1 Software component . . . . . . . . .
5.1.1 CANoe . . . . . . . . . . . .
5.1.2 CAPL Browser . . . . . . . .
5.1.3 Structure of a CAPL program
5.2 Experimental Setup . . . . . . . . .
5.3 Implementation of the ISOTP . . . .
5.4 FRTP Implementation . . . . . . . .
5.5 Interaction of APIs functions . . . .
5.6 Documenting API using Doxygen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
34
34
40
.
.
.
.
.
.
.
.
.
42
42
42
43
45
46
47
54
57
61
6 Validation
6.1 Error Handling . . . . . . . . . . . . . .
6.2 Test Cases . . . . . . . . . . . . . . . . .
6.2.1 Unexpected Frames . . . . . . . .
6.2.2 Flow Control parameter test . . .
6.2.3 Timeout behaviour test . . . . .
6.2.4 FlexRay Transport Protocol Test
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
65
65
68
72
73
7 Summary and future work

75
7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
List of abbreviations
77
List of Figures
78
List of Tables
80
Bibliography
81
1 Introduction
This chapter goes for presenting a reasonable understanding of the purpose for the development of the master thesis topic Concept and implementation of a universal UDS API
for modular use in test environments for vehicle communication tests. It gives a brief idea
about the organization of the thesis. Knowing the problem statement and the goal of the
thesis, it also gives an agreeable understanding of the category of the master thesis comes
down under.
1.1 Motivation
Today diagnostics are having a fundamental impact from designing through production
to service. In last few years vehicle diagnostics is experiencing a fast development. The
amount of Electronic Control Units (ECUs) in cars has been rising gradually and is closing
100 control units in a vehicle. At the same time, the unpredictability and the capacities
of an ECU and vehicle system is also increasing fundamentally. Test and verification of
diagnostic and control functions are important to certify that diagnostic communication
works reliably.
The growth and presentation of new diagnostic concepts and diagnostic solutions offer substantial potential for automotive Original Equipment Manufacturers (OEMs) and suppliers
for realizing efficiency. Electronic Control Unit (ECU) is one of the most critical elements in
the automotive area (or in todays vehicle). Thus, without a diagnostic standard, it is hard
to calibrate and maintain the ECUs because only the developers have expert knowledge of
their ECUs [UDSP].
Implementations of the diagnostics protocol varies from OEM to OEM. In spite of such a
wide differences, all ECUs are obliged to become suitable for common diagnostics standards
so they demonstrate the same conduct and give regular interfaces.
For that the developer needs to develop a system that assists large portion of the diagnostic
standard defined that called the Unified Diagnostic Services (UDS) protocol. UDS protocol
was characterized by the International Organization for Standardization (ISO) standard in
context to support different diagnostics standard. [ASOF] Diagnostics communication will
be utilized when exact information is essential or it permits a basic and reasonable access
to the black-box ECU.
At last diagnostics is connected differently in the technology area, development and production stage in a few applications, whether they be in development of communications, of
1.2. PROBLEM STATEMENT
CHAPTER 1. INTRODUCTION
ECU functions, of flash functions or in Hardware-in-the-Loop (HiL) and in the integration

of ECUs.
1.2 Problem Statement

A gateway receives CAN frame from tester and transmits this frame to the target bu and
responses are transmitted from the ECU to the tester via gateway in the reverse way as
shown in figure 1.1. There may be some frame change happen in the gateway for example
Tester
SW Gateway
FlexRay ECU
Fig.: 1.1: Software gateway routing the diagnostics request between CAN bus and target bus
(FlexRay)
length of the frame by adding or removing the padding bytes or conversion of CAN identifier
to the FlexRay target address.
For the diagnostics of the FlexRay ECU, first of all diagnostic services must send to the
software gateway from the tester. Then software gateway has to route the packet to the
FlexRay target address as shown below in figure 1.2. Therefore software gateway converts
CAN ID to the FlexRay source address and target address using conversion formula. Because
of this conversion takes place between CAN ID and FlexRay addresses, FlexRay provides
expected result with delay. Consequently sometime ECU will not give an exact result with
gateway such as time out error due to gateway delay.
1.3. STRUCTURE OF MASTER THESIS
Fig.: 1.2: Time delay occurs during gateway transfers frame
1.3 Structure of master thesis

This master thesis subdivides mainly into two parts: on the one hand, the thesis aims for
a concept development of the universal UDS API. On the other hand, to implement the
selected UDS services using a developed concept. Since this thesis does not fall under the
category of a formal proof, the reliability of the concept and implementation is proven by
processing of various test cases with focus on respective test criteria. Hence this master
thesis falls under concept development and implementation of concept.
This master thesis is divided into several chapters, which handle different topics. The structure of the thesis is as follows:
The first chapter gives a brief introduction, motivation and objectives of the thesis. Additionally a short explanation about problem statement. It also gives a view about which type
of this thesis work.
The second chapter provides a prerequisite knowledge to understand the work in later chapters. It explains the fundamentals of the modern bus architecture and bus protocols. The
chapter further gives the explanation of the transport protocol and a brief introduction to
the Open Diagnostic Data Exchange (ODX) file. It also talks about the diagnostic protocol applied in the todays vehicle. This section represents how diagnostics performed in
the vehicle. And Unified Diagnostic Services (UDS) protocol explained in more detail with
diagnostic request and response message structure.
Chapter three gives the state of the art or the current industry scenario/problems. It provides
an explanation of how currently diagnostic request performed by software gateway.
Chapter four provides the key architectural and implementation background information
for concept development and structure of the modular UDS Application Program Interface
(API).
In chapter five, ISO-TP implementation and FlexRay TP implementation procedures are
discussed. It also gives an overview of the Vector CANoe tool and techniques.
1.3. STRUCTURE OF MASTER THESIS
Chapter six covers the different test cases like unexpected frames, flow control parameter
test and timeout behaviour test for validation of transport protocol implementation module
in CAPL API. These test cases are explained with screenshots from CANoe trace window.
The final chapter discusses the summary of the thesis and ideas on further research possibilities are mentioned.
The chapter/headings are divided in up to three levels, e.g. 2.3.4. First usage of an abbreviation is written along with its full form. The caption of a figure or a table briefly explains
it.
2 Basics
The following chapter provides the necessary fundamentals for the thesis. For better understanding of the thesis and following topic some basics required on the CAN protocol, FlexRay
protocol, ISO-TP, FlexRay-TP and UDS protocol which are part of my thesis work. These
are briefly explained in the following chapter. At the end of the chapter brief introduction of
Open Diagnostic Data Exchange (ODX) format which gives an overview about the process
chain with ODX database.
2.1 Vehicle networking

The first networking vehicles appeared in the early 1990s on the market, all control devices
were connected via a single bus system. With the addition of other electronic systems
and as more and more control units have been installed the bus load increased and it was
necessary to integrate additional buses into the vehicle. The bus architecture was more or
less resulting from the desire for the shortest possible wiring and random installation of the
control devices. After the systems have become increasingly prone to error by the collision
in ECU communication and the increasing complexity, adopted from the 2000s a structured
architecture, in which the ECUs are grouped according to application area and the individual
bus systems were coupled together via a central gateway. This architecture has survived until
today. Figure 2.1 schematically illustrates the bus architecture of a vehicle.
In a modern vehicle a number of different bus system is used. The mentioned bus systems are
CAN (Controller Area Network), FlexRay, LIN (Local Interconnect Network) and MOST
(Media Oriented Systems Transport). Each of these systems has been designed for a special
case of application. The essential part of this thesis is CAN bus and FlexRay, which are
explained in Chapter 2.1.1 in more detail. The other bus systems are discussed only briefly
here.
LIN is a low-cost bus system and was developed as a low cost alternative to CAN. It is
mainly used to connect sensors and actuators to a control device. In this case, the controller
acts as a bus master and all other members as slaves. As can be seen in figure 2.1, is the
bus master himself is usually associated with another bus so that LIN is designed as a pure
sub-bus. The maximum data rate from LIN is 20 kbit/s in comparison to other systems very
low. Therefore LIN is mainly used in the field of comfort electronics, where no high data
rates are required, for example for seat and door control units [ZiSch].
MOST has been specially developed for the infotainment bus system. Typically, MOST
is used in networking radio, navigation system,telephone, internet connection and driver
2.1. VEHICLE NETWORKING
CHAPTER 2. BASICS
Diagnose-Ethernet
Diagnose-CAN
ECU
ECU
ECU
ECU
Powertrain CAN
Central Gateway
ECU
Chasis FlexRay
ECU
ECU
ECU
ECU
ECU
Infotainment
Most
ECU
Body
CAN 2
ECU
ECU
Body CAN 1
ECU
ECU
ECU
ECU
Sub-Bus LIN 1
ECU
Sub-Bus LIN 2
Fig.: 2.1: Modern Vehicle architecture [ZiSch]
information system. In these applications the requirement of real-time capability is less and
transmission security in the foreground, but rather a high data rate. A special feature of
MOST is the ring structure and the optical transmission using optical fibers [ZiSch].
Ethernet is currently used by some car manufacturers (BMW) for diagnostic purposes in
order to connect a diagnostic tester to the gateway of the vehicle (see figure 2.1). There are
also efforts to use Ethernet long-term in automobiles, for example, as a substitute for MOST
or FlexRay. Ethernet-based systems are currently still in development and are not available
in production vehicles.
2.1.1 CAN Control Area Network

The CAN bus was one of the first bus that has established over a large area in the automotive
sector. CAN was developed to reduce the amount of wiring in the vehicle by Robert Bosch
and standardized internationally later by ISO ([ISO11898-1] - [ISO11898-5]). CAN define
the layers 1 and 2 (physical layer and data link layer) of the OSI layer model. [ZiSch]
Properties of CAN:
Real time communication is possible
Flexibility in the configuration
Multicast reception with time synchronization
Multimaster transmission
CHAPTER 2. BASICS
Error detection and signaling

System wide data consistency
Layers of CAN
Physical Layer
Physical layer mainly concern with physical signaling specially bit timing, bit encoding and
synchronization. It is also responsible for physical medium connection and interfaces. In
CAN up to 1 Mbit/s for high-speed CAN (CAN-C, ISO standard 11898-2) or 125 Kbit/s with
a low speed CAN bus (CAN-B, ISO 11898-2) can be achieved. Both types of bus use two
twisted wires (CAN high (CAN-H) and CAN Low (CAN-L)) and identify the current level
by differential voltage between the individual wires. That result in a higher susceptibility to
interference is achieved. In high speed CAN a difference of 2 volts corresponds to a dominant
signal. If both lines have the same voltage, this corresponds to recessive signal. The low
speed CAN uses different voltage levels for transmission. Thereby the incompatibility can
be explained with high speed CAN. A dominant signal corresponds to the low speed CAN a
voltage difference of 2.2 V. A difference of 5 V corresponds to a recessive signal. [ZiSch]
Data Link Layer: Bus access and arbitration
Carrier Sense Multiple Access/Collision Resolution (CSMA/CR) method is used for CAN
bus access. A CAN message has no source or target address, but unique message identifiers.
CAN messages are broadcast so each participant can in principle receive any message. Each
node is free to start the transmission of its message. The message begins with start of
frame bit followed by an identifier. At the same time, it is checked whether the signal level
on the bus corresponding to the bit being sent. If this is not the case, it means that at
the same time another node sends a message with a higher priority. When several nodes
start the transmission, the system responds by applying wired-and arbitration to stop the
conflicts over bus access. Based on the message identifier, a CAN node can decide whether
the message with the highest priority (lowest binary value of the identifier) or not. The
highest priority message is assigned first bus access. The process of deciding which message
is sent on the bus is called arbitration. [ZiSch]
Figure 2.2 shows an example of the process of arbitration. ECU 1 and ECU 2 transmit
simultaneously. Until the sixth bit both message identifiers are the same, the sixth bit is
dominant at ECU 1 and recessive at ECU 2. The message of ECU 1 is therefore higher
priority. ECU 2 detects this by comparing the signal level on the bus with the transmitted
bit and terminates the transfer.
CAN message format
For data transfer on the CAN bus, a message frame is made. It includes the data to be
transmitted in a characterized sequence. Figure 2.3 illustrates the structure of a CAN
frame.
Start Bit
CHAPTER 2. BASICS
11 bit Message Identifier
00
11
11
11
00
11
00
00
ECU1
Losses the arbitration
11
Collision
00
ECU2
Signal on
the bus
0 Dominant Level
1 Recessive Level
Fig.: 2.2: Bit arbitration [ZiSch]
S
O
F
Message
Identifier
Control
Bits
Data
11 or 29 Bit
7 Bit
0.64 Bit
Header
CRC
15 Bit
Payload
ACK
E
O
F
10 Bit
Trailer
Fig.: 2.3: CAN Frame structure [ZiSch] [SPAS]
Header
The start bit marks the beginning of a new frame and is always dominant. The message
identifier (priority of the message) is amounts to 11 bits in the standard format or 29 bits
in the extended format. After that 7 control bits are sent that contains the message length
(Data length Code (DLC)). The header has an overall length of 19 or 37 bits depending on
which type of message identifier is used. [ZiSch]
Payload
Here the actual data content of the CAN message is transmitted. A message length can be
between 0 and 8 bytes. The exact length of the data to be transmitted is previously specified
in the header as DLC. [ZiSch]
CHAPTER 2. BASICS
Trailer
After a payload a Cycle Redundancy Check (CRC) is transmitted with the length of 15 bits.
This is used to check whether it has come to bit errors during transmission. Then the ACK
slot follows. The receiver acknowledges that the frame is received correctly by sending a
dominant bit in the ACK slot. Then sender checks whether the message was transmitted
correctly. The conclusion of CAN frame is the End of Frame (EOF) field. It indicates the
end of the message and end of bit stuffing. This ACK and EOF field has a length of 10 bits.
By combining CRC with ACK and EOF trailer results in a total length of 25 bits. [ZiSch]
2.1.2 ISO-Transport Protocol

The ISO 15765-2 standard defines a transport protocol (ISO-TP) that allows a segmented
transmission of messages [ISOTP11]. The ISO transport protocol is on the fourth layer
(transport layer) of the OSI layer model. The CAN-Bus only allows a transfer of 8 bytes of
user data per frame. The ISO TP defined a transmission method that allows to send up to
4095 bytes via the CAN-bus. For this, the messages to be sent are segmented and individual
CAN frames divided [ISO15765-2].
In the following section we focus on transport protocol. After a short introduction, first
consider the transport protocol for CAN.
Function Overview
This section 2.1.2 describes the basic functions of the transport protocol for unacknowledged
segmented/unsegmented data transfer (USDT/UUDT). The following functions must be
supported by the transport protocol:
Segmentation
The primary task of the transport protocol is to transfer messages which cannot be transmitted as a single Protocol Data Unit (PDU) due to their length. Messages which contain
more data than can be transmitted within a single PDU are segmented by means of the
transport protocol and divided into multiple, separate PDUs. This procedure can also be
implemented on the data link layer. The segmentation of the message must then be carried
out in PDUs of the corresponding data link protocol. [VWTP]
Flow control
The flow control mechanism of the transport protocol is used to configure the sender to
match the properties of the receiver (timing, available receive buffer, readiness to receive).
[VWTP]
Error detection
The error detection mechanism of the transport protocol informs the higher-level software
layers on the receiver side about the successful or unsuccessful receipt of a message. This prevents incorrect or incomplete messages from being forwarded to an application. [VWTP]
Single
Frame
CHAPTER 2. BASICS
Bit 74
Bit 30
0x00
DL
Data (Diagnostic Message)
07 Data Bytes
1 Byte PCI
Bit 74
First
Frame
Bit 30
0x01
DL11..8
Bit 70
DL7..0
06 Data Bytes
2 Byte PCI
Bit 74
Consecutive
Frame
Bit 30
0x02
SN
07 Data Bytes (last CF<7 Bytes)
1 Byte PCI
Flow Control
Frame
Bit 74
Bit 30
Bit 70
0x03
FS
BS
Bit 70
STMin
3 Byte PCI
Fig.: 2.4: ISO-TP message structure [ZiSch]
ISO-TP Message Structure

ISO-TP defines different types of message. An ISO-TP message is also referred to as Protocol Data Unit. Here four different types of PDU are defined as shown in figure 2.4:
Single Frame (SF) is used when the message length is less than or equal to 7 bytes because
the first byte is used for Protocol Control Information (PCI). With single frame first four
bits of the PCI byte are set to 0. The four least significant bits of this byte contain the data
length of the payload.
If diagnostic message is bigger than 7 bytes, segmentation is required. A First Frame (FF)
indicates the beginning of a segmented transmission. The length of the entire message in
the four least significant bits of the first byte and the entire second byte is specified. So
there are 12 bits available for the data length (DL) specification. So the valid values of DL
are from 8 to 0xFFF (4095) for normal addressing. In addition the header, the first frame
contains the first six bytes of the diagnostic message.
10
CHAPTER 2. BASICS
The Consecutive Frame (CF) transports the individual segments of a segmented message.
The transport protocol on the receiver side assembles all the consecutive frames and transfers
the complete message to the higher level protocol layer after correctly receiving all the
consecutive frame PDUs. On the receiver side the Sequence Number (SN) is used to detect
the errors or to compile the segments. The low nibble (0. . . 3 bits) of the PCI byte indicates
the SN. The valid values are 0 to 0xF.
The Flow Control (FC) frame is sent by the receiving node to transmitting node for flow
control of the transmission. The flow control frame contains 3 bytes which together form
a PCI. The first byte begins in the upper four bits with value of 3, indicates that there is
flow control. In the four least significant bits of the first byte shows a Flow Status (FS).
Thus the transmitter to receiver can signal whether a segmented transmission Clear To Send
(CTS), Wait or Overflow. The second byte BS stands for Block Size and shows how many
consecutive frames need to be sent in one block. The last byte STmin shows the minimum
separation time between consecutive frames to be noticed. [ISO15765-2]
An ISO-TP frame is always 8 bytes long and unneeded bytes filled with the padding byte
0xAA or 0x55 [VWTP].
Structure of the message transfer
There are two data transfer methods of ISO TP: single frame data transmission and multiple data transmission [VWTP]. The figure 2.5 shows the single frame data transmission
(Unacknowledged Unsegmented Data Transfer). In a CAN frame, there is a maximum of
8 data bytes of user data. The data length of the ISO TP message can reach a maximum
of 4095 bytes. If an ISO TP message length exceeds the data length of 8 data bytes, the
UDS message must be segmented. The data transfer with segmentation is called multiple
frame transmission (Unacknowledged Segmented Data Transfer). The figure 2.6 shows the
ISO-TP multiple frame transmission.
Fig.: 2.5: ISO-TP single frame data transmission [VWTP]
11
CHAPTER 2. BASICS
Fig.: 2.6: ISO-TP multiple frame transmission [VWTP]
Error Handling
Both the transmitter and receiver monitor the data transmission with a timer. The receiver
monitors the time required by the transmitter for sending a Consecutive Frames. If this
takes long time, the transmission is aborted and data already transmitted are discarded.
Similarly the transmitter monitors the time for the receiver to send the flow control frame.
12
CHAPTER 2. BASICS
Again the transmission is aborted and data already transmitted are discarded if a time out
is detected. The maximum waiting time for a frame is one second. [VWTP]
In addition to timing errors, errors in the message structure must be recognized. If an
erroneous PDU is detected the frame is ignored or if a transmission is in progress, cancelled
it. Possible errors in the message structure are: incorrect sequence number in consecutive
frames, invalid message length, and invalid flow status in the flow control frame or an invalid
PDU type. [VWTP]
Unexpectedly arriving frames are always ignored, with the exception of single frame and
physically addressed first frame. Functionally addressed first frame, consecutive frame and
flow control are always ignored. [VWTP]
2.1.3 FlexRay
This section will explain the fundamentals of FlexRay.
CAN is suitable for data exchange between electronic control units for most applications
within
a
car,
however
it
has
some
restraints.
Latency cannot be predicted due to the
event-driven media access and it is not guaranteed that a low priority message is sent at
all. Moreover, the bandwidth of CAN is limited to 1 Mbit/s. A redundant design which
is mandatory by law for new techniques as
X-by-wire (X = Brake, Steer) is not provided as well. These restrictions were main
reason to found the FlexRay Consortium in
2000 by BMW, Daimler-Benz, Motorola and
Philips.
Fig.: 2.7: FlexRay Logo [FLXC]
Another great feature of FlexRay is a bandwidth of 10 Mbit/s on two separate channels. The channels can be used to send redundant messages in order to increase the safety
of the system or to double the bandwidth by sending two different messages.
Since FlexRay is a deterministic vehicle bus a node is only allowed to send in its defined time
slots contrary to the event-driven CAN. FlexRay overcomes these restrictions by dividing
the medium into static and dynamic time slots. FlexRay is subdivided into communication
cycles based on a common global time base called Macrotick (MT). The next pages hand a
step by step introduction into FlexRay and details on the most important parts.
The figure 2.8 illustrates the structure of the four parts of a FlexRay cycle: static (red) and
dynamic (green) segment, symbol window (yellow) and Network Idle Time (NIT) (white).
The static and dynamic segments are used for communication purposes. Time Division
Multiple Access (TDMA) grants the media access within the static segment.
13
CHAPTER 2. BASICS
A minislot routine is used within the optional dynamic segment. The symbol window and
NIT have organizational reasons: the optional symbol window is reserved for transferring
symbols within the network, e.g., the Media Access Test Symbol (MTS) for testing the
functionality of bus guardians. However, the feature is unused in most current applications.
The NIT is mandatory and the bus is silent. As figure 2.8 illustrates, the NIT is used for
offset correction in every fourth slot.
FlexRay messages are packed within frames. The rough segmentation is in header, actual
payload and Cyclic Redundancy Code (CRC)-trailer which is visible in the figure 2.8. Each
frame is followed by the Channel Idle Delimiter (CID).
gdNumberOfStaticSlots
slot
1
slot
2
slot
3
slot
4
slot
n-1
slot
n
Symbol
Window
cdCAS = 30bit
Static Frame
header
payload
Media Test
CID
Symbol
gdActionPointOffset
gdSybolWindow
trailer CID
gdActionPointOffset
gdStaticSlot
Cycle [2n+0]
Cycle [2n+1]
Cycle [2n+2]
Cycle [2n+3]
static dynamic SW NIT

Synchronization
gNumberOfMinislots
n n n dynamic n n
+1 +2 +3 slot n+4 +5 +6
n
+x
Network
Idle Time
Dynamic Frame
header
payload
gdNIT
channel offset correcidle tion segment
trailer DTS CID
gdMinislotActionPointOffset
gdOffsetCorrection
Start
variable Duration
Fig.: 2.8: FlexRay TDMA Structure [VFPR]
Static Segment
Every node participating in the FlexRay cluster gets one or more timeslots in which the
node is allowed to send. This routine is called TDMA, and is used within the static segment.
The number of static slots is configured by variable gNumberOfStaticSlots. The schedule
is defined in a Field Bus Exchange Format (FIBEX)-file and cannot be changed during
runtime. The static segment is optimized on the availability of bandwidth on a certain
time. A channel unique Frame-ID identifies a frame corresponding to the timeslot number
14
CHAPTER 2. BASICS
in which the frame is sent. For instance a frame has the ID 1 will be sent only in slot 1.
The slots within the static segment are synchronous on both channels. A node must send in
its assigned slot, however, it has the possibility to send a null frame, i.e., the payload is set
to a bit spring of zeros. The payload length, however, remains unchanged. Nullframes are
indicated in the header. Receiving nodes do not further process nullframes. All messages in
the static segment must have a common length. [MaRa] [SPAS]
Communication Cycle N
Static Segment
Slot 1
Slot 2
ID 1
ID 2
Dynamic Segment
Slot 3
Slot 4
Symbol Window
Slot 5
Slot 6
Slot 63
ID 5
ID 6
ID 63
Network Idle Time
Frames with a
fixed ID
Macrotick
MT
MT
MT
Microtick
Fig.: 2.9: Static Segment [MaRa]
Dynamic Segment
The dynamic segment is optimized on fully utilizing the bandwidth. The segment is split
into minislots shorter than timeslots in the static segment. Minislots can be configured using
gNumberOfMinislots. The consecutive numbering of minislots follows up the static segment.
The dynamic slot counter is incremented every minislot as long as neither node transmits
a message. The frame-ID of the message and dynamic slot counter must match in order
to send a frame. If a node sends a message, a dynamic slot lasts for as many minislots as
necessary and the dynamic slot counter is incremented afterward. A DTS (Dynamic Trailing
Sequence) is appended to the frame in order to end the transmission simultaneously with a
minislot. Regardless of the utilization the dynamic segment has a fixed, determined length
to ensure a constant and deterministic cycle time. Messages can only be sent if they fit in
the remaining minislots within the cycle. [MaRa] [SPAS]
Figure 2.11 illustrates the static and dynamic segments and the respective media access.
The dynamic segment in this example consists of 8 minislots. The red message on channel
B cannot be sent since the message lasts longer than the remaining number of minislots.
FlexRay does not provide an automated transmission repeat with a higher priority, i.e., with
a lower frame ID within the next dynamic segment. This must be organized within FIBEX.
15
CHAPTER 2. BASICS
Communication Cycle N
Static Segment
MS 1
MS 2
Dynamic Segment
MS 3
MS 4
Frame ID 1
MS 5
MS 6
Symbol Window
MS 7
Network Idle Time
MS 8
MS 9
Frame ID 3
Slot 1
Slot 2
MT
MT
MS 10
Frame ID 5
Slot 3
Slot 4
Slot 5
Macrotick
MT
Microtick
T
Fig.: 2.10: Dynamic Segment [MaRa]
On the basis of cycle multiplexing the Slot-ID for nodes in the dynamic segment can change
every cycle. Thus the transmission priority of the respective messages differs as well.
Minislots
Slot 1
Slot 2
Slot 3
Slot 4
Slot 5
11
14
10
Fig.: 2.11: Flexray Static and Dynamic Segments with Media Access [IXXF]
2.1.4 FlexRay TP
Flexray Transport protocol is compatible with ISO 15765-2, the transport protocol for CAN
which was described in previous section 2.1.2. Since only the modifications and extensions
are shown in comparison with ISO-TP in this section 2.1.4. The message format was slightly
modified from ISO-TP for CAN. In contrast to CAN, where the transmitter and receiver
address is mapped to the CAN message identifier, the address information in FlexRay must
be transmitted within the message as shown in figure 2.13.
The known CAN single, consecutive and flow control frames were modified for FlexRay.
There are segmented and unsegmented transmissions with and without confirmation.
16
CHAPTER 2. BASICS
Sender
Receiver
Sender
Receiver
TP
TP
TP
TP
Transmit
Transmit
SF
FF
FC
CF-1
CF-2
CF-3
Cycle
Repeat
BS = 0,
STmin = 0
Cycle
time
CF-4
CF-5
Fig.: 2.12: FlexRay transport protocol [ZiSch]
Max 254 Byte

2 or 4 Byte
TA
Address Info
SA
1.5 Byte
Data Bytes
PCI
Protocol Control Info
Payload
Fig.: 2.13: PDU format of FlexffRay TP [ZiSch]
The figure 2.14 shows the format of the PCI parameter for the FlexRay transport protocol.
The SF extended and FF extended is extension of the SF and FF with enlarged data length,
in which the following numbers of data bytes are transmitted. It allows larger data block
so that unsegmented message (SF Extended) with FlexRay transport protocol, it is able to
represent significantly longer message up to 246 byte of data length. The protocol overhead is
maximum 8 byte. Therefore the maximum payload that can be transmitted by one FlexRay
PDU is up to 246 byte. FlexRay transport protocol uses approximately the equal protocol
mechanisms as the ISO-TP. And with segmented message (FF Extended + CF) able to
represent total data length of 4 GB compared with CAN is only 4 KB. [ZiSch]
17
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
Frame Type
1 Byte
Bit 74
2 Byte
SF Single
0h
DL3.0
SF Extended
4h
0h
FF First
1h
FF Extended
5h
0h
Consecutive Frame
2h
SN
3h
FS
Flow Control FC
3 Byte
4 Byte
5 Byte
Bit 30
DL- Data Length

FS- Flow Status
DL7....0
DL11.0
DL31....0
BS
BS- Block Size
ST- Separation Time
STmin
SN- Sequence Number
Fig.: 2.14: Format of the PCI fields [ZiSch]
2.2 Diagnostic
This chapter will help the reader to acquire a basic understanding of diagnostic protocol.
The first section summarizes overview on automotive diagnosis. The following sections
explain the structure and content of diagnostic protocol in detail. This includes diagnostic
request-response structure and addressing methods.
2.2.1 Overview on automotive diagnosis

Automotive diagnostics is the entire field of investigation and testing to determine the presence or absence of problems in an automobile, and if there are problems, to determine their
problems and causes. Automotive diagnostics communication is information exchange between vehicle electronics and testing devices. It is relevant to all ECUs and tester systems.
It is like reading/writing into memory of ECU and interface with other programs in the
ECU.
There are two types of automotive diagnosis: 1) On-Board diagnosis 2) Off-Board diagnosis
On-Board diagnosis (Self Diagnosis)
On-board diagnosis is a generic term referring to a vehicles self-diagnostic and reporting
capability. Nowadays, in on-board diagnosis built in function of ECUs used for self-diagnosis
and to monitor sensors and actuators. Virtually all modern vehicles include an ECU. When
the ECU detects a problem it cannot fix, it trips the malfunction indicator lamp and stores
a trouble code for later retrieval that points the mechanic toward possible systems or mechanisms involved. [MaSu]
The On-Board Communication describes the communication between control units and can
be divided into three main areas.
18
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
1. High speed (High speed CAN, FlexRay)

2. Low speed (Low speed CAN, LIN)
3. Multimedia (MOST)
Off-Board diagnosis (Service diagnosis)
The off-board diagnosis, however, describes the communication between the controller and
external tester. Off-board communication is also called diagnostic communication because
it uses a special diagnostic communication protocol. [MaSu] In contrast to the on-board
communication with CAN or FlexRay in which each control unit sends its information to
all, in the off-board communication the diagnostic tester always starts communication. It
sends a request such as: "Are there emission related fault in the system?" or "What is the oil
temperature?". This request so called diagnostic request goes to one or more control devices.
These answers with the appropriate diagnostic responses. So there is a clear role: the tester
asks and ECU response. This communication principle known as the Request/Response
method, see figure 2.15.
Fig.: 2.15: Off-board communication [EMOT]
Specific diagnostic devices (testing tools) combined with measurement technology, remaining
bus simulation and databases. Therefore off-board diagnosis is enhanced diagnosis. Offboard diagnosis can be roughly applied into three parts.
1. Workshop and emission related tests
2. End Of Line (EOL) and Flashing
3. Application (Can Calibration Protocol (CCP) and Universal Measurement and Calibration Protocol (XCP))
Before the introduction of the Diagnostics on CAN (ISO 15765), diagnostic communication
was based on the K-line (Key Word Protocol (KWP) ISO 14230). Today, the diagnostic
protocol UDS (ISO 14229-1 - Unified Diagnostic Services) is widely accepted and established. UDS provides the unification demanded by vehicle manufacturers and suppliers, and
displaces the proprietary protocols step by step. UDS is broadly accepted as the diagnostic
protocol in current vehicle developments.
19
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
2.2.2 UDS Protocol

Unified Diagnostic Services (UDS) is a communications protocol that is used for diagnostic
services in the automobile. It describes the layers 5 and 7 of the OSI layer model (session
layer and application layer). The UDS protocol is standardized in ISO 14229 international.
UDS is independent of the underlying bus system, most commonly it is implemented on
CAN and ISO-TP. The implementation of UDS on CAN and ISO-TP is described in ISO
15765-3 and is also called "UDS on CAN". [ISO15765-3]
UDS specifies the communication between the diagnostic tester and vehicle ECU. The relationship between the tester and the control unit is a client-server relationship. The control
device (server) offers a variety of diagnostic services provided by the tester (client) may be
requested.
Diagnostics Communication Principle
ECU diagnostic communication using UDS protocol is becoming significant in automotive
diagnostic application. The basic principle of diagnostics communication in UDS protocol is
request/response method. The diagnostic tester sends a request to one or more ECUs and
ECU sends a positive or negative response. [ISO14229]
Figure 2.16 explained request-response method. Where parameter P1 indicates the interbyte
time for ECU response, P2 indicates the time between end of Tester request and start of
ECU response, P3 means time between the end ECU response and start of the next tester
request or between ECU responses during multiple response mode and P4 point out interbyte
time for tester request.
Fig.: 2.16: Diagnostics communication principle [EMOT]
Addressing Method
In general the diagnostics messages are exchanged via the bus where ECU is connected. For
this reason the destination type of diagnostic messages must be specified. There are two
types of addressing modes available.
Physical Addressing of ECU (1:1):
In the physical addressing mode, unique request and response CAN IDs for each ECUs in the
20
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
system. Tester communicates with one only ECU at a time. (Point to point communication).
Physical addressing is illustrated by an example with diagnostic tester and n number of
control devices as shown in figure 2.17. Here it can be seen only requested ECU1 (0x7E0)
is responded to the tester.
(0x7E0)
ECU#1
(0x7E8)
Physical CAN ID
Request (0x7E0)
(0x7E0)
Tester
Physical CAN ID
Response (0x7E8)
(0x7E0)
(0x7E0)
ECU#2
ECU#n-1
ECU#n
Fig.: 2.17: Physical addressing mode [VWUDS]
Functional Addressing of ECU (1:n):

Tester communicates with more than one ECU. Each ECU sends response serially to the
tester (Point to multi point communication). In functional addressing tester sends request to
all ECU (ECU# 1, ECU# 2, ECU# n-1, ECU# n) as explained in figure 2.18 and response
from all ECUs which support the request to the tester.
(0x7DF)
ECU#1
Functional CAN ID
(0x7E8)
Request (0x7DF)
(0x7DF)
ECU#2
Physical CAN ID
Response (0x7E8)
(0x688)
(0x7DF)
Tester
ECU#n-1
Physical CAN ID
Response (0x688)
(0x73F)
Physical CAN ID
(0x7DF
)
Response (0x73F)
ECU#n
(0x2FF)
Physical CAN ID
Response (0x2FF)
Fig.: 2.18: Functional addressing mode [VWUDS]
For a functional addressing, the request CAN ID will be same for all the ECUs in a given
system but response CAN IDs will be unique for each ECUs (same as physical).
UDS request and response format
Request format:
In request message first byte is called a Service Identifier (SID) to distinguish the various
21
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
diagnostic services and the tasks to be done. The remaining bytes contain parameters and
data. [ISO14229]
Request
Length
Service ID
Subservice
ID
Data 1
Data 2
Data 3
Data 4
Data 5
Example: 02 10 01 where 02 indicate the request length and 10 and 01 indicate the service
ID and subservice ID respectively.
Positive Response Format:
The ECU responds to a diagnostic query with either a positive or negative response. The
positive response in the first byte contains the SID again. This is basically the bit 6 set.
Mathematically, this corresponds to an addition of 0x40 to SID. [ISO14229]
Response
Length
Service ID
+ 0x40
Subservice
ID
Data 1
Data 2
Data 3
Data 4
Data 5
Example: 02 50 01
Negative Response Format:
If the request transmitted to the ECU is incorrect the ECU sends negative response. The
Negative Response Message is usually a three-byte message: The first byte is always 0x7F.
The second byte contains a copy of the SID and the last byte of the so-called response code.
This describes the error. [ISO14229]
Response
Length
7F
Service ID
Negative
Response
Code (NRC)
Request: 03 10 02 00
Negative Response: 03 7F 10 13
ECU response 03 7F 10 13 where 7F means it is negative response, 10 is SID and 13 indicates
the incorrect message length (NRC).
The error code of the response is an encoding that represents a justification of the negative
response.
2.2.3 UDS Services

Application layer services are usually referred to as diagnostic services. The application layer
services are used in client-server based systems to perform functions such as test, inspection,
monitoring or diagnosis of on-board vehicle servers. [ISO15765-3]
The services can be divided in to following functional groups: Diagnostics and Communication management, Data Transmission, Stored Data Transmission, Input/Output Control,
22
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
Remote Activation of Routine and Upload/Download. The following table 2.1 shows a list
of diagnostics services of UDS.
Function
Group
SID
Diagnostics and
Communication
Management
Data
Transmission
Stored Data
Transmission
Upload/Download
UDS Service
0x10
0x3E
0x27
0x28
0x85
0x87
0x86
0x22
0x23
0x2E
0x3D
0x2A
0x2C
0x14
0x19
DiagnosticSessionControl
TesterPresent
SecurityAccess
CommunicationControl
ControlDTCSetting
LinkControl
ResponseOnEventService
ReadDataByIdentifier
ReadMemoryByAddress
WriteDataByIdentifier
WriteMemoryByAddress
ReadDataByPeriodicIdentifier
DynamicallyDefineDataIdentifier
Clear DTC
Read DTC
0x34
0x35
0x36
0x37
RequestDownload
RequestUpload
TransferData
RequestTransferExit
Description
Control
Diagnostic Session
and
Bus Communication
Read and write of

measured values
and ECU data
Read and write
the DTC code
Read and write
large data blocks
Table 2.1: List of diagnostics services of UDS [ISO14229]
Diagnostic Session
To protect services from unauthorized access, UDS also specifies different sessions. In each
session, a tester only requests specific set of diagnostics services to ECU. The different sessions are the Default Session (0x01), Programming Session (0x02), and Extended Diagnostic
Session (0x03). In addition to this vehicle manufacturer implement further manufacturer
specific sessions. For VW / Audi, these are the "End-of-Line Session (0x40)" and the "Development Session (0x4F)". [VWUDS] [SUNX]
The DiagnosticSessionControl service is applied to allow different diagnostic sessions in the
ECU. A diagnostic session energizes a specific set of diagnostic services and/or functionality
in the ECU. In the "Default Session simple services are available such as reading and erasing trouble code or retrieving system data. ECU always starts the default diagnosis session
when you powered up. The "Extended Diagnostic Session" also offers services that affect
the system performance, such as overwriting of system parameters. In the "programming
session no data can be read from the control unit, but the flashing of the control device is
possible. The VW-specific "End-of-Line Session" offers services for parameterizing and cali-
23
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
brating the ECU. This session is only used in the production. The "Development Session" is
intended for development purposes, it allows all UDS services offered by server [VWUDS].
Read Data By Identifier (RDBI) (0x22)
This service is used to read out data from the system. The data type involved is described in more detail in the client request and within the system response, by means of
the RecordDataIdentifier parameter. The clients request can contain either one or more
RecordDataIdentifier parameters (each 2 bytes). The data to be issued by the system includes digital/analog input and output signals (measured values), system status information,
identification data as well as other internal system data. [SUNX]
Message structure
Table 2.2 shows the request message for reading out data with the identifier. The service
identifier is set to 0x22. The 2-byte "Record Data Identifier" (data identifier) are defined by
automobile manufacturers. At VW Group data identifiers are defined for data addressing
in a specification. The function of the request packed the UDS-Request message and passes
the request message to the transmission function of ISO-TP.
Name
Value
SID Req SID

(1 Byte)
0x22
Record Data Identifier

(1 Byte)
XX

(1 Byte)
XX
Table 2.2: Request message of the Read Data By Identifier [ISO14229]
Table 2.3 shows the positive response. The service identifier (SID) is defined with 0x62 (0x40
+ 0x22). The data identifier (Record Data Identifier) is equal to the data identifier of the
request message.
Name
Value
Positive Res SID

(1 Byte)
0x62

(1 Byte)
XX
Data Record
Byte1...ByteK
Table 2.3: Positive response message of the Read Data By Identifier [ISO14229]
Table 2.4 shows the negative response of the read data by identifier. The service identifier
of the response (ResSID) is specified with 0x7F and the service identifier of the request
(ReqSID) is defined with 0x22. The list of error code is already defined in table 2.7.
Name
Value
Negative Res SID

(1 Byte)
0x7F
Read Data By Identifier ReqID

(1 Byte)
0x22
Error Code
(1 Byte)
0x22,0x31 or 0x33
Table 2.4: Negative response message of the Read Data By Identifier [ISO14229]
24
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
Data identifiers are addressing parameters that are defined by ISO, VW AG, Audi AG or
other car manufacturers. Data can be stored in a memory in the address that is addressed
by a particular data identifier. A data identifier has a length of 2 bytes.
Read DTC (RDTC) (0x19)
Table 2.5 shows the request message to read the diagnostics trouble codes. The service
identifier is set to 0x19. It used to read the errors or notes that have occurred or been
detected. The error code type 0x02 means that read the corresponding error code by status
mask. The DTC status mask describes the states of the error code. [SUNX]
Name
Value
Req SID
(1 Byte)
0x19
DTC Information Type

(1 Byte)
02
DTC Mask Record

(1 Byte)
XX
Table 2.5: Request message of the Read DTC [ISO14229]
With this UDS service the client can request diagnostic information stored in a non-volatile
memory (notes/errors) of a server including current status information. Table 2.6 shows the
positive response of ReadDTCByStatusMask.
#1
#2
#3
#4
#n
Read DTC Information Positive Resp SID

Report Type
DTC Status Availability Mask
Group of DTC
DTC#1 HighByte
DTC#1 MiddleByte
DTC#1 LowByte
Group of DTC
DTC#m HighByte
DTC#m MiddleByte
DTC#m LowByte
0x59
0x02
XX
XX
XX
XX
XX
XX
XX
Table 2.6: Response message of the Read DTC [ISO14229]
Error Handling
If a UDS request is not answered within 500ms from the server, it is repeated. A request
is sent while a maximum of three times. The client receives no response after the third
repetition; an error message is passed to the application. [VWUDS]
If the server due to high load not be able to process the request, then server (ECU) require
to send the request Busy repeat request with negative error code (0x21). The client then
sends the same request again after some time. [VWUDS]
25
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
If a request is received correctly, but still server can not be sent positive response, the server
sends a negative response with error code Response pending (0x78). This indicates the
client that the request is currently being processed and the final answer will be delayed
[VWUDS]. Table 2.7 shows definition of the error code.
Hex
12
13
21
22
31
33
35
36
7F
78
Description
Sub Function Not Supported
Incorrect Message Length Or Invalid Format
Busy-Repeat Request
Conditions Not Correct
Request Out Of Range
Security Access Denied
Invalid Key
Exceed Attempts
Service Not Supported In Active Diagnostic Session
Busy- Response Pending
Table 2.7: List of negative response code [ISO14229]
2.2.4 Open Diagnostic Data Exchange

Vehicle systems, particularly ECU systems are getting more and more complicated. Additionally diagnostics requirements are also expanding respectively. Therefore diagnostics
efforts have been increasing in production, development and service area. The diagnostic
functionality using diagnostic description formats is difficult to control for manufacturing
diagnostic specification, ECU supplier diagnostic specification, and development diagnostic
specification. Since the need of standardized description format for diagnostics, configuration and flash programming data is crucial. Therefore Association for Standardization in
Automation and Measuring Systems (ASAM) created a standardization of process, data and
tool over the manufacturers, suppliers and tool vendors.
What is ODX?
ODX stands for Open Diagnostics data eXchange and is standardized data format for
exchange of vehicle diagnostic data. It was specified by ASAM and is also in ISO 22901
standardized.
The ODX format is used to describe all the data needed for vehicle diagnostics consistency
and to enable a standardized data exchange between vehicle manufacturer and system suppliers. ODX used Extensive Markup Language (XML) for implementation format. [ASAM]
Figure 2.19 shows the process chain with an ODX database. The central database contains
all vehicle-related diagnostic data. The basic diagnostic data of a vehicle are specified by
the vehicle manufacturer. [ASAM]
26
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
Fig.: 2.19: Process chain with ODX [ASAM]
The different development departments of the manufacturer can access these and forward
them to the system supplier if necessary. The system supplier in return provide diagnostic
data in ODX format of their systems to the vehicle manufacturer, the one maintains it into
the database. [ASAM]
In production, the ODX data for end-of-line testing and parameterization and calibration
of systems are used. In the service area data used for troubleshooting and diagnosis of
defective vehicles. All subsequent software updates in the workshops are possible with
ODX. [ASAM]
27
3 State of the art
The subject of the automotive diagnostic has been rigorously researched in the past decade.
In this chapter literature representing the current state of the art will be reviewed.
The current state of the art of vehicle diagnosis
Nowadays, most of the vehicles ECU are diagnosable. With the help of vehicle diagnostic
error of the control units can be determined quickly. For this purpose, protocols have been
developed. These protocols describe the mechanisms and requirements for vehicle diagnostics, for example: UDS, OBD, KWP 2000, SAE, ODX, OTX (Open test sequence exchange)
and MVCI (Modular Vehicle Communications Interface). With the help of ODX a database
for diagnosis is defined. In this database, the vehicle diagnostics standard are described.
MVCI standardized communication interfaces. SAE protocols define the bus interfaces for
vehicle diagnostics. The OBD-2 diagnostic sockets of vehicles allow access to ECUs. To realize the access VCIs (Vehicle Communication Interface) have been developed. The VCIs, for
example: MTS 6516 and MTS 6520 that allow connection between the host computer and
buses of the vehicles. The Bosch VCI "MTS 6516" supports both the SAE J2534 interface
and the ISO 22900-2 Diagnostic Protocol Data Unit (D-PDU) API [Bosch]. The Bosch VCI
"MTS 6520" is developed in MVCI standard [Bosch]. For example iDEX and VAS 5163 are
used as a diagnostic software on a computer. iDEX (Intelligent Diagnostic Environment for
ODX) is a diagnostic software and was developed by the company "Berner and Mattner"
for Audi AG. Now iDEX is further developed by Bertrandt. This software offers the following options: ECU Identification, Read/Clear diagnostic trouble code, Flashing, Read
measured value blocks, Access authorization, and Actuator test [BeMa].
VAS 5163 is a diagnostic development tool for Volkswagen. This software allows vehicle
diagnostic functions for example: identification of the control devices, reading and deleting
of the error memory, encoding and reading of the measured values [Soft]. This vehicle
diagnostic software is also used in workshops. Workshop processes are divided into steps:
Order acceptance and service and repair procedure [Konr]. A diagnosis software is used
in step "Service and Repair Procedure" for determining the electronic service information
[Konr]. The electronic service information include for example: technical information of
the control devices, vehicle diagnostic information and repair instructions [Konr]. With this
diagnostic software the diagnostic tasks can be solved, but to carry out the tasks a computer
and a VCI is also required.
28
CHAPTER 3. STATE OF THE ART

Current situation at Bertrandt
The diagnostics request are currently performed with a diagnostics service of bus analysis
software Vector CANoe. This service request can be performed directly on CAN bus by
using a software gateway for the diagnostics of other bus system like FlexRay bus.
CANoe
Diagnose
Service
CAN
FlexRay
Software
Gateway
ECU
Fig.: 3.1: Current Situation
Here software gateway is used for diagnosis of ECU. By applying software gateway, tester
can communicate easily to each ECU. The challenge for the software gateway is to route the
packet to the requested ECU in the correct time.
Diagnostics on ISO-TP on FlexRay
CANoe supports a large number of features for the improvement of diagnostics in ECUs and
vehicles overall. All features are accessible on the CAN bus with ISO transport protocol.
At the same time, not all features are accessible on non CAN bus system and not every
transport protocol is supported. A diagnostics gateway can adapt CAN diagnostics features
for other bus system in most of situations. [TPLAH]
A diagnostics communication on FlexRay bus is based on the FlexRay own transport protocol
as defined in section 2.4. Since transport protocol ISO compliant behaves and communicates
a FlexRay ECU via the gateway to an external ISO-TP tester.
On FlexRay, PDUs (Protocol Data Units) are exchanged between the communication partners. The definition of PDU such as name and position in the FlexRay communication
matrix defines.
This section defines only
1. Structure of the PDU with specific addressing
2. Routing between CAN and FlexRay via the gateway with specific addressing adaption
FlexRay ISO-TP PDU for Diagnose
For diagnostic communication normal addressing method is used as defined in section 2.5.2.
The FlexRay ISO TP PDU includes a data length of 12 bytes. The first data byte target
address is specifically extended for FlexRay. This is the destination address, so the receiver
of the PDU. The second data byte source address is also specifically extended for FlexRay.
29

The second byte is the sender of the PDU. The actual ISO-TP data are in the data bytes
4. . . 12.
1
Target
10
11
12
Source
ISO-TP Frame
Fig.: 3.2: FlexRay ISO-TP PDU for diagnose [TPLAH]
Routing ISO TP Communication CAN-FlexRay-CAN

In an ISO-TP communication between FlexRay ECU and CAN Tester, the CAN ID are
mapped to the target/source addresses as follows:
The target address or source address of the gateway route as a diagnosis is 0x10. The target
and source addresses of the control units based on the following formula: Target address =
Request CAN ID 0x700 [TPLAH].
ISO TP Communication from CAN to FlexRay
CAN Message
0x718
Gateway
FlexRay
PDU
ISO- TP Fra me
Target: 0x718 - 0x700 = 0x18 / Source = 0x10
0x18
0x10
ISO- TP Fra me
Fig.: 3.3: Example CAN-FlexRay Routing [TPLAH]
ISO TP Communication from FlexRay to CAN
FlexRay
PDU
0x10
0x18
Gateway
CAN Message
ISO- TP Fra me
Response CAN ID: 0x18 + 0x76A = 0x782

0x782
ISO- TP Fra me
Fig.: 3.4: Example FlexRay-CAN Routing [TPLAH]
30

The response CAN ID mapped if the target address of the gateway is 0x10 addressed for
diagnosis. Response CAN-ID = Source address + 0x76A [TPLAH]
From the current situation, the pros and cons of the software gateway are concluded in
table 3.1 and therefore it can be determined that software gateway needs to be replaced in
future.
Advantage
Able to reuse CAN implementation for
FlexRay ISO-TP test
Disadvantage
Additional work required because of
modifications in K-Matrix, FIBEX file
during I-Step (Integration step) in software gateway
Maintenance effort and the error rate
of the software gateway are very high
Other bus system can be integrated
only with great effort
Not possible to change the address
while CANoe run
Table 3.1: Advantage and disadvantage of software gateway
31
4 Concept
After the detailed description of the necessary fundamentals and current situation, the following section describes the concept in detail. This section discusses the universal UDS
API concept without software gateway according to OSI layer. This section closes with an
exemplary realization of selected UDS service.
4.1 Modification of the ISO/OSI model

Figure 4.1 explains that there is a logical link between the application layer of the tester
(client) and the application layer of the ECU (server). They support diagnostic communication using diagnostic requests and responses, which are virtually moved from their original
vertical position to a horizontal one.
Logical Link
1.Request
Client Instance
Server Instance
2.Indication
3.Response
4.Confirmation
1.Request
3.Response
Instance
Fig.: 4.1: Diagnostic communication from the perspective of the OSI moedl [MaSu]
The communication between the subordinated layers has no relevance for the specification
of diagnostic services. Usually, not all layers of the OSI model are used for diagnostic
communication. Often, three or four layers are sufficient to accomplish diagnostic communication. [MaSu]
32
4.1. MODIFICATION OF THE ISO/OSI MODEL
CHAPTER 4. CONCEPT
Individual protocols have to be specified for each layer which is involved, such as protocols
for the transport layer, also referred to as transport protocols [MaSu]. Some vehicle manufacturers and suppliers specified proprietary protocols for specific layers of the OSI model
such as Volkswagen proprietary transport protocol VW Transport protocol.
So off board communication that called communication between the ECUs and diagnostic
tester is explained in figure 4.2 as per OSI layer. By the ISO/OSI reference model, the
distribution of tasks in communication between ECU and tester is shown in below figure
4.2.
Tester
ECU
Response
Request
Diagnostic Protocol
ISO/OSI Layer model
Application Layer
Layer 7
Diagnostic Protocol
Transport Protocol
Transport Layer
Layer 4
Transport Protocol
Bus System
Data Link Layer

Layer 2
Physical Layer
Layer 1
Bus System
Fig.: 4.2: Protocol stack according to ISO/OSI layer model [EMOT]
The diagnostic protocol describes the layer 7 (Application Layer). Application Layer presents
UDS services for example Read Data By Identifier. Diagnostics message varies in the
length; if the UDS message does not fit into the single message then transport protocol
breaks up a long UDS message into segments that can be transported over bus network.
On controller side, the message is received at the level of the transport protocol layer and
each segmented messages are reconstructed to get back the original message. The ECU will
then give the response and this is again segmented by transport layer. At the tester side
this process is in reverse order.
33
4.2. SYSTEM REQUIREMENTS
CHAPTER 4. CONCEPT
4.2 System Requirements

The purpose of creation of this thesis is to develop a universal UDS API that should be able
to send diagnostic request without software gateway. Figure 4.3 illustrates the conceptual
design of the different bus module. The desired situation is to send the request directly to
the ECU from tester and also receive response from ECU in reverse order in a same way.
Second requirement for fulfilling desired situation is that API should be expandable and
modular so in future someone can develop further this existed API. It is possible to make the
customizable UDS API by creating various bus module for particular bus such as FlexRay
module and LIN module for FlexRay and LIN bus, respectively. Second most important
thing is transport protocol that makes API more dynamic. It could be done by applying
distinct transport protocol module according to bus system. For instance Flexray transport
protocol applies only for FlexRay bus so one can make further expandable if new version of
FlexRay transport protocol is released in future.
UDS
UDS
ISO-TP
ISO-TP/FRTP/DoIP
CAN
CAN
FlexRay
LIN
Ethernet
CAN
CAN <-> FR GW
FlexRay
ECU
ECU
ECU
ECU
ECU
Fig.: 4.3: Desired Situation
Fig.: 4.4: Current Situation
4.3 Modular design of the API

The aim of this thesis is to develop a concept for a universal UDS Application Programming
Interface (API) that can send a UDS request to different bus systems for example Controller
Area Network (CAN), FlexRay, Local Interconnect Network (LIN) and Ethernet. For this
purpose, first of all a concept have to be set up for a modular design of the API. Each
module is available for a particular bus system and should be expandable in retrospect with
other modules/bus systems.
Figure 4.5 shows the modular design of the universal UDS API. The different modules can
be seen as per ISO/OSI layer. Every module has been described in detail step by step in
the following section.
34
4.3. MODULAR DESIGN OF THE API
Tester
CHAPTER 4. CONCEPT
CAPL
API
ODX/PDX
Import
UDS Protocol
Application Layer
Transport Protocol
Transport Layer
Data Link Layer
CAN
Disturbance
FlexRay
Disturbance
Physical Layer
LIN
Disturbance
Ethernet
Disturbance
BUS Interface
Communication Bus
ECU
Fig.: 4.5: Modular design of the universal UDS API
CAPL API:
CANoe contains a CAPL Browser which can use as an alternative to a normal text editor
to create CAPL programs. The CAPL language allows writing programs for individual
applications. For example, in the development of network nodes, the problem often arises
that the remaining bus nodes are not available yet for tests. The system environment can
be emulated with the help of CAPL, e.g. the data traffic of all remaining stations can be
emulated.
With CAPL one can also write programs to analyze data traffic which are adapted to problem
or programs for a gateway a connection element between two buses so that data can
be exchanged between different buses. The universal UDS API is written with the help of
CAPL programme.
Transport Protocol Module:
Transport protocol module splits the data from diagnostics module (long data blocks) into
small blocks which can be transmitted to respective bus system (CAN, LIN, FlexRay and
Ethernet). It transmits data via different transport protocol as per different bus system in
two ways. First one is single frame transmission in which data fit into one CAN frame.
Another one is multiple frame transmission where transmission of data do not fit into one
35
CHAPTER 4. CONCEPT
CAN frame and therefore have to be send step by step. Two example has been taken for
UDS module
22 F1 87
Transport protocol module

03
22 F1 87 XX XX XX XX
Bus interface (CAN interface)

03 22 F1 87 XX XX XX XX
CAN
0x715
03 22 F1 87 XX XX XX XX
Fig.: 4.6: Transport protocol module process
explanation of transport protocol module process. Diagnostic module shall send a Read Data
By Identifier request to the network. Diagnostic request data 0x22 0xA1 0x93 values are
overgiven to transport protocol module. Transport protocol module will be used single frame
transmission because transmission of short data which fit into one CAN frame. The second
example represents the case of multiple frame transmission where diagnostic request have
to be send step by step because of long response. Therefore basic mechanism of transport
protocol applied here. First sender transmits FF PDU, in response receiver responds with a
Flow Control frame and informs the sender about BS and STmin. After receiving FC from
receiver sender transmits data with CF and it stops transmission after block size.
Transport protocol module adds TP related protol data see below example. There is data
length 03 filled by transport protocol module. Also it fills padding byte with predefined
value when PDU has unused byte.
Example: single frame transmission (normal addressing)
Time
2.084300
CAN ID
715
Data bytes
03 22 A1 93 xx xx xx xx
Example: multiple frame transmission (UDS service 22hex ReadDataByIdentifer)
36

2.093219
2.093953
2.112942
2.112942
2.112942
CHAPTER 4. CONCEPT
77F
715
77F
77F
77F
10 17 62 A1 93 45 56 5F
30 00 00 xx xx xx xx xx
21 41 69 72 62 61 56 57
22 31 30 42 50 41 56 57
23 32 35 30 xx xx xx xx
715 = CAN ID: sent by tester

77F = CAN ID: sent by ECU
1 = first frame
0 17 = number of data byte (17hex = 23dec)
62 A1 . . . 5F = data byte (UDS data)
3 = flow control frame
0 = continue to send (tester shall start transmission of data)
00 = block size: 00 = no flow control shall be used
00= STmin (time between two CF) Shall be >0ms if ECU can not handle 100 % busload
2 = consecutive frame
1 = sequence counter: mechanism for the receiver to check that no CAN message was lost
41..57 = data
2 = sequence counter increased by 1
31..57 = data
3 = sequence counter increased by 1
32..30 = data
xx..xx = padded by TP module
UDS protocol module

Application layer services are usually referred to as diagnostic services. The application layer
services are used in client-server based systems to perform functions such as test, inspection,
monitoring or diagnosis of on-board vehicle servers.
The flow diagram is represented how requested UDS service gives the answer shown in figure
4.7. The UDS service request take up the decision one by one on based of service identifier,
message length, and sub-function. For instance, if tester sends a request message 03 22 F1
89 AA AA AA AA, ECU response will be 07 62 F1 89 30 31 30 35. Negative response
message of request out of range is 03 7F 22 31 AA AA AA AA.
Disturbance
Disturbance module is intended for transport protocol conformity testing. It supports to validate the transport protocol that are used. This is achieved by possible protocol parameters
such as invalid message length, invalid PCI type, incorrect flow status in terms of corrupt
frames and unexpected frames.
For example check that controller ignores the single frame with invalid CAN data length
less than 8 (incomplete frames). Here tester sends a single frame with frame length of 7,
03 22 F1 A3 AA AA AA (DLC=7). The electronic control unit must not respond to the
request.
37
CHAPTER 4. CONCEPT
Start of service
Request SID
supported ?
No
Negative response
Service not supported
No
Negative response
Invalid message length
No
Negative response
Sub-function not supported
Yes
Length
Supported ?
Yes
Sub-function
supported ?
Yes
Positive
response ready?
Negative response
Response pending
No
Yes
Positive response
End of service
Fig.: 4.7: Process of performing UDS service at application layer
Another example with unexpected first frame while receiving, first tester sends a long request
to the electronic control unit. After the first long request is fully received, the tester sends
another request (First Frame) immediately.
10 09 22 F1 87 F1 87 F1 (API: long request)
38
CHAPTER 4. CONCEPT
30 0F 05 AA AA AA AA AA (FC from electronic control unit)

10 09 22 A3 F1 89 F1 (API: unexpected first frame request)
Bus Interface:
Bus interface connects a PC or notebook to a bus system (CAN,LIN,FlexRay and Ethernet).
From the figure 4.8, the general bus interface can be seen for the following bus systems CAN,
FlexRay, LIN and automotive Ethernet those are going to apply in UDS API that makes it
easy to use bus interface from the Vector CANoe. There one can assign bus specific channels
and ports to send or receive messages on the bus.
In this thesis ECU was connected with bus interface hardware VN7600 FlexRay Interface
from Vector. The table 4.1 displays following standard Vector hardware for bus interfaces.
These are ideally suited with Vectors CANoe.
Bus Interfaces
PCMCIA
PCI
USB
CAN
FlexRay
LIN
Ethernet
Fig.: 4.8: Access to the bus interface
Bus system
Interface
Connection
CAN/FlexRay
LIN
CAN/LIN
Ethernet
CAN/LIN
CAN/LIN/FlexRay
VN7600
VN1600
CANboardXL
VN5610
CANcardXL
VN8900
USB
USB
PCI
USB
PCMCIA
USB
Table 4.1: Vector hardwares for bus interface
Bus interfaces hardware are also provide by different manufacturer such as ETAS, PEAK
System, Softing and so on.
39
4.4. CONCEPT REALIZATION
CHAPTER 4. CONCEPT
4.4 Concept realization

Figure 4.9 explains how concept flows using different test modules of API. Example of UDS
service "Read DTC Information 19 Hex" has been illustrated step by step.
Read DTC Information
API
19
03
02
19
UDS
2C
02
ISOTP
2C
ECU
ECU
10
09
59
02
API
30
00
00
AA AA AA AA AA
ECU
21
11
22
2C
01
23 45
33 AA AA AA
ISOTP
AA
10 09 59 02 2C 01 23 45
59 02 2C 01 23 45
ISOTP
UDS
ODX
DTC
0x012345
0x112233
Error type text

Circuit open
ECU defect
UDS
Fig.: 4.9: concept realization with Read DTC information service
Summary
This chapter has contributed concept approach information to implement the universal UDS
API that can send UDS request directly to ECU without a software gateway. All above
discussed approaches contribute to an API for ECU diagnostic communication as shown in
figure 4.10. The UDS services are carried out in UDS API through APIs transport protocol
module and it sends the request message. The received message is interpreted on the API
and returned as readable answer. This approach is basically the same in all services.
40
4.4. CONCEPT REALIZATION
Read Data By
Identifier
CHAPTER 4. CONCEPT
Read DTC
Information
Clear Diagnostic
Information
UDS API
Identifier
DTC 1 Status Mask 1

DTC 2 Status Mask 2
DTC 3 Status Mask 3
Fig.: 4.10: Block diagram of UDS API
41
Yes/No
5 Implementation
After the detailed descriptipn of the necessary fundamentals and concept development, the
following section describes the ISOTP protocol and FRTP protocol implemtation using Communication Access Programming Language (CAPL) programming in detail. This section also
discusses the simulation tool CANoe.
5.1 Software component

In the following section the software component is described. This includes the measurement and simulation software CANoe, which controls the bus interface for the simulation of
complete bus systems. The implementation of the simulation is implemented using C-like
programming language CAPL.
5.1.1 CANoe
The measurement and simulation software CANoe developed by the company Vector. It
provides comprehensive functions that are frequently used by vehicle manufacturers and
their suppliers in the entire development process of networks or individual control units in
automotive vehicles. CANoe provides engineering support in the areas of analysis, simulation
and diagnostic testing.
As briefly mentioned above, CANoe allows simulations of various bus systems, including
their subscribers. A configuration contains all simulated bus systems. The simulation of
the participants on the bus systems is realized by so-called CAPL node. CAPL is a special
event-driven programming of the vector.
In CANoe the following windows are available for the simulation and analysis.
1. Simulation setup: In the Simulation Setup, the overall system is displayed graphically
with networks, devices and all network nodes. All options for parameterizing the
Simulation Setup are selected in this window.
2. Simulation window: The tree structure of CANoe is displayed in simulation setup
window. The tree structure is configuration of all bus systems and their hierarchal
settings with CANoe
3. Measurement Setup: The data flow is displayed graphically in the Measurement Setup.
All options for parameterizing the Measurement Setup are selected in this window.
4. Graphics Window: Chronological signal charts are graphically displayed in the Graphics Window. The display is in an X-Y diagram along the time axis.
42
5.1. SOFTWARE COMPONENT
CHAPTER 5. IMPLEMENTATION
Fig.: 5.1: CANoe configuration windows
5. CAN statistics window: The Statistics Window displays statistics about bus activities
during measurement. This window can be inserted into the Measurement Setup via
the shortcut menus of the relevant function blocks (bus statistics etc.). All bus events
that arrive at the input of the Measurement Setup block are evaluated for this purpose.
If a database is assigned to the channel, statistics can also be evaluated individually
for each available bus node.
6. Write Window: Information on the progress of the measurement are output here.
Write instructions from CAPL programs appear in this window.
7. Trace Window: The purpose of the Trace Window is to record bus activities during
measurement. All the messages received at the input of a Trace block are displayed as
lines of text in the Trace Window.
5.1.2 CAPL Browser

CAPL is a part of a CANoe. CAPL browser is provided as a development environment by
Vector. CAPL browser is an easy-to-use tool for creating and modifying CAPL programs.
43
Using CAPL Browser, CAPL programs can be written for stimulating, simulating, testing
and diagnostics. CAPL programs are added in CANoe as CAPL program nodes. Event
handlers serve as an input in CAPL, with which external events can be responded (e.g. the
arrival of certain messages).
Fig.: 5.2: CAPL Browser
Figure 5.2 shows the opened CAPL programs distributed among the individual tabs. The
display of the individual CAPL program is divided into a Navigator and a Text Editor.
1. Text editor: The entire source code of the CAPL program is displayed in the Text
Editor and it can be edited there. You can declare variables and implement event
handlers and functions there. The Navigator displays the structure of the file as
a tree view. The following categories may be present: Test functions, Test cases,
Test procedures, User defined functions, Includes, Variables and Event handlers (event
procedures)
2. Navigator: Navigator is used to navigate the desired sections in source code quickly and
easily (e.g. an event handler).The CAPL Browser monitors the symbols, i.e. database
symbols, diagnostic parameters, system and environment variables are updated automatically if changes are made.
3. CAPL function explorer: All available predefined functions and event handlers are
displayed in the CAPL Function Explorer. They can be inserted into an opened CAPL
program using drag and drop.
4. Output window: Compiler messages on the currently active program are displayed in
the output window
44
5.1.3 Structure of a CAPL program

CAPL program consist of two parts:
Declaration of global variables
Declaration of user defined functions and event procedures
Global variables
In the Browser, global variables are declared in the Variables section. The data types
DWORD, LONG, WORD, INT, BYTE and CHAR can be used analogously to their use
in the C programming language. The data types FLOAT and DOUBLE are synonyms
and designate 64 bit floating point numbers conforming to the IEEE standard. CAN/LIN
messages to be transmitted on the bus by the CAPL program are declared with message.
A timer event is created with timer or msTimer. The timer does not begin to run until it
has been started in a on timer event procedure. After the timer has elapsed the associated
event procedure is called. A variable of the type timer can only be accessed by the predefined
functions setTimer and cancelTimer.
Event procedures:
CAPL is an event-controlled programming language; special event handlers (event procedures) are always executed when a specific event (e.g. pressing a button) occurs. In the
CANoe environment, it is primarily bus events, e.g. the sending of a specific signal, which
occur. For this reason, the CAPL Browser offers a large number of predefined event handlers
for bus events.
CAN event procedure
on message
The event procedure on message is called on the receipt of a valid CAN message.
on message 0x783 {
output(this);
};
The procedure on message 0x783 will be called up when a message with the identifier 0x783
is received.
FlexRay event procedure
on frPDU <PDU name>
This procedure is called when a PDU with the corresponding name is received.
Declaration of user defined functions
CAPL functions are used among other things to modularize code for repeated use, and to
form interfaces. The syntax is C-like, but there are a number of supplemental features not
included in C:
A missing result type is interpreted as void
45
5.2. EXPERIMENTAL SETUP
An empty parameter list is permitted as in C++

Overloading of functions (i.e. multiple functions with the same name but different
parameter lists) is possible as in C++
A parameter check is performed as in C++
Arrays of arbitrary dimension and size may be passed
CAPL Include files
An Include file can be integrated directly in the code of the CAPL program. It is treated
similar to a function library. An include file has to be programmed in the same programming
language as the main CAPL program.
CAPL Include files are not simply included as text include. All variables and functions that
are included via the Include files will be available as global variables and functions.
In CAPL any number of Include files can be inserted in the Include program section via the
syntax #include:
includes
{
#include"inclFile1.CIN"
}
The name of the Include file is freely selectable. In the example above the extension .CIN
is used. The Include file has to be a syntactic correct CAPL program. This means: - The
Include file consists of a sequence of sections, e.g. variables, on message etc. - The Include
file can include other files.
5.2 Experimental Setup

This experimental setup is quite similar to the simulation view in CANoe. In addition to the
pure simulation also bus communication can be monitored from real systems with CANoe.
To monitor the communication on a real bus additional hardware is required, which makes
the connection between the computer and the bus system. This bus interface hardware also
comes from Vector Company. There are various models available in market with different
features and bus interface. During this thesis has been working with the VN7600 interface.
This was connected via USB to the computer. It has shown from figure that ECU has been
connected to the tester (PC) through Vector bus interface hardware.
46
5.3. IMPLEMENTATION OF THE ISOTP
Fig.: 5.3: Experimental setup
5.3 Implementation of the ISOTP

The universal UDS API has a modular design and consists of different modules for different
functionality such as UDS module for various diagnostic services, CANTP and FRTP for
transport protocol layer. These modules are programmed as a .can and .cin file in the
API. The structure of the API as an illustration represented in figure 5.4. These individual
modules are associated with important functions and these functions has been wriiten in a
modules .cin file. A detailed description of the modules and functions can be found in the
following section.
Fig.: 5.4: API Structure
This section mainly aims at describing the different stages of the ISOTP protocol implementation and the subsequent steps in detail. This is done with the help of a potocol parameter
calculation. It should also be noted that, this chapter only focuses on the implemetation
and not the verification of the ISOTP implementation.
ISOTP transport protocol parameter calculation
47

PDU-Type
FlowControl
FC PCI Byte1
0 0 1 1 FS
Byte2
BS
Byte3
STmin
Byte4
0xAA
Byte5
0xAA
Byte6
0xAA
Byte7
0xAA
Byte8
0xAA
Table 5.1: Structure of a Flow Control PDU [VWTP]
Flow Status
0
3 0xF
Meaning
Continue To Send (CTS)
The CTS Flow Control parameter signals the sender to continue the transfer of CF PDUs. The receiver signals the
sender that it is ready to receive the number of CF PDUs
specified in the BlockSize (BS).
Wait (WT)
The WT FlowControl parameter signals the sender to wait
before transferring any further CF PDUs. The transmission of further CF PDUs continues after receiving a CTS FC
PDU.
Overflow (OVFLW)
With the OVFLW Flow Control parameter, the receiver signals the sender to cancel the current transmission of segmented message. The receiver may only send the OVFLW
FlowStatus to the FC PDU which immediately follows an FF
PDU. With this Flow Status, the receiver signals the sender
that the available receive buffer is not sufficient to receive the
segmented message with the length indicated by the FFDL.
Reserved
Table 5.2: Meaning of the Flow Status parameter [VWTP]
Block Size
The Block Size parameter specifies to the receiving node how many CF PDUs the sending
node must transfer sequentially in one block before it has to wait for another FC PDU. In
the final block of a segmented message, the number of CF PDUs may be less than the value
specified in the Block Size. The receiver must not change the BS value transferred to the
sender in the first FC PDU while transferring a segmented message. During the transfer, the
sender of a segmented message must be able to process a change in the BS value transferred
by the receiver. The Block Size (BS) parameter zero (0) signals the sender that all of the
CF PDUs can be transferred in one block. The receiver does not send any further FC PDUs
during the receipt of the segmented message. [VWTP]
Sequence Number
In CF PDUs, the Sequence Number is used to determine the sequence of the data segments
contained in the CF PDUs. On the receiver side, the Sequence Number is used to detect
errors or to compile the segments. The Sequence Number is encoded in bits 0...3 (low nibble)
48
of the PCI byte of a CF PDU. The valid values are zero (0) to fifteen (0xF).The Sequence
Number of the CF PDU which immediately follows the FF PDU is one (1). The Sequence
Number of each subsequent CF PDU increases by one (1) in each case. FC PDUs between
CF PDUs have no effect on the numerical sequence of the Sequence Number. After reaching
Sequence Number fifteen (0xF), the Sequence Number of the following CF PDU is set to
zero (0). [VWTP]
STmin (Minimum Separation Time)
The second Flow Control parameter is the minimum Separation Time that has an impact on
the data transmission. The STmin parameter is the minimum time between two successive
CF PDUs which must be observed by the sender. The Separation Time begins with the
complete transfer of a CF PDU and ends with the transfer of the following CF PDU to the
data link layer. [VWTP]
STmin
0x00
0x01-0x7F
0x80-0xF0
0xF1-0xF9
0xFA-0xFF
Meaning
The transmitter may send its ConsecutiveFrame as fast as it
can.
Separation Time Range (0 ms - 127 ms)
The values for STmin in the range from 0x00 to 0x7F must
be interpreted as absolute values in milliseconds. The transmitter has to wait at least this number of milliseconds (ms)
before sending another ConsectiveFrame.
Reserved
Seperation Time Range (100 s - 900 s)
The values for STmin in the range from 0xF1 to 0xF9 must
be interpreted in increments of 100 microseconds beginning
with 100 s for 0xF1.
Reserved
Table 5.3: Value of the Separation Time parameter [VWTP]
The total number of required Consecutive Frame CF which are required to transmit the
pending data bytes in multiple frame transmission case is calculated by:

RequestedP DU F F P ayloadDataBytes
Number Of CF =
Def aultCF P ayloadDataBytes

(5.1)
Number of segmented PDU transferred =

N umberOf CF + N umberOf F F + N umberOf F C + N umberOf ResponseF rame (5.2)
Total amount of flow control PDUs depends on the Block Size. Here two different cases have
been taken to calculate the number of Flow Control frames require :
1. Block Size = 0 (BS = 0) and
49
2. Block Size between 1 and 255

Case 1: Block Size = 0
Block Size is zero (0) that points out the sender that no further Flow Control shall be sent
all the while segmented transmission. The sender shall send all pending data bytes without
any wait for Flow Control from the receiver side. Here only one Flow Control is transmitted
after receiving First Frame. It requires for receiving Consecutive Frames. . Hence the total
amount of PDUs can be calculated:

Number Of PDU =
+2
(5.3)
No additional FC is required because BS equal to zero. This results in
Total STmin = (N umberof CF 1)ST min
(5.4)
Case 2: Blok Size between 1 and 255

If Block Size is not equal to zero (0) then sender wait after number of Consecutive Frame
transmission as per Block Size for a next Flow Control from receiver. Hence transmitter should send this many Consecutive Frames before waiting for a Flow Control frame.
Therefore total amount of PDUs can be derived in this case by considering total number of
Consecutive frame and total number of Flow Control.
& RequestedP DU F F P ayloadDataBytes '
d
e
Number Of Flow Control =
(5.5)
BS
In this case total amount of PDUs =1 (FF)+ Number Of CF + Number Of FC

= 1(F F ) +
& RequestedP DU F F P ayloadDataBytes '
d
e
+
BS
(5.6)
If BS between 1 and 255 then on each end of a block separation time does not take place
because a Flow Control (FC) PDU is not required in the last block. This results in
Total STmin = (N umberOf CF dN umberOf F C 1e 1)ST min
(5.7)
From all derived equations, we can conclude that block Size depends straightforwardly on
ECUs buffer size. Block Size equal to zero is feasible if sufficient buffer size is available for
processing received data and also ECU is directly connected to tester. If ECU communicates
with the tester through gateway then block size depends on buffer size of gateway.
The send function of ISO-TP contains the sub-functions: CAN-frame packaging, Transmit
single-frame and transmit first frame. After receiving the UDS request, it passed to the
50
ISO-TP module, then the message is packed in a CAN frame. The service information of
application layer can be the request IDs or response IDs of the UDS service. The data of the
application layer can be the parameters of the UDS service and the data of the transport
layer is the data of the ISO-TP message. The ISO-TP message contains the PCI and data.
The PCI of the ISO-TP has already been explained and the data can be a UDS message.
The destination address is equal to the request address and the source address is equal to
the response address. The CAN frame packaging function sets the CAN address, then it
adds the Protocol Control Information and the data of the application layer. Finally, it
passes to the function send single frame or send first frame. When the data length of the
transport layer does not exceed 8 bytes, the transport protocol module sends the single frame
otherwise it passes the message of the function send first frame. In the function send first
frame first ISO-TP message must be segmented. The message segmentation feature packed
the ISO-TP message in the First Frame and the Consecutive Frames. After transmission of
the First Frame data, Flow Control frame is received and after termination of Flow Control
frame sender sends the Consecutive Frames.
51
Start
Press key T
Check the UDS request

message length
Length<7
Send Single Frame
Length>7
Send First Frame
Process SF
Receive FC
Store BS and STmin
value
Send CF
Process CF
Yes
Is the last
CF?
No
Process CF
End
Fig.: 5.5: Process flow of sending ISOTP message
Once the total number of expected consecutive frame is determined from the message length,
the transport layer receives a Consecutive Frame. The sequence number is read using a bit
mask from the first byte of the frame. The sequence number must be correspond to the
expected value otherwise the transmission aborted and an error message pass to the higher
protocol layer. The number of consecutive frames received is synchronized with the block
size. Once this is achieved, a flow control is transmitted. Block Size and separation time
(STmin) parameter used by the sender are taken from Flow Control frame received from
receiver.
52
Start
No
Check if frame
is expected
Yes
Read Sequence No.
No
Check if
Sequence No.
is expected
Wrong SN
Yes
Yes
Check if frame
is last CF
No
No
Check if Flow
Control have
to send
Yes
Send FC
End
Fig.: 5.6: Flowchart of checking conseutive frame and sending flow control frame function
The CAPL program reads the value of the received response frame from CAN ECU and
evaluates the response for sending FC to ECU.
1
2
3
4
5
6
7
8
9
10
on message
{
by te bCounter ;
// R e a c t i o n t o r e c e i p t o f t h e frame
i f ( t h i s . i d == iRespID )
{
byte baRXLocalData [ 8 ] ;
// copy data c o n t e n t s t o a r r a y baRXLocalData [ ]
f o r ( bCounter = 0 ; bCounter < 8 ; bCounter++) {
baRXLocalData [ bCounter ] = t h i s . byte ( bCounter ) ; }
53
5.4. FRTP IMPLEMENTATION

tp_handel_ ( baRXLocalData , 8 ) ;
11
12
13
5.4 FRTP Implementation

Currently, the diagnostic communication is standardized on the CAN bus. The diagnosis
via FlexRay is based on the FlexRay own transport protocol.
FlexRay simulation setup
To create a FlexRay configuration using a FIBEX database file, the first step is to create a
new configuration and select the FlexRay template. After this go to the simulation setup and
navigate in the tree view to Networks>FlexRay Clusters>FlexRay>Databases
and add the FIBEX file. So FlexRay simulation setup is ready according to FIBEX file. The
last step is to assign the simulated ECU node that is target for the requests.
Fig.: 5.7: FlexRay simulation setup in CANoe
The communication in FlexRay consists 64 communication cycles (0 to 63) that continuously

repeated (see Figure 5.8). The required number of communication cycles for transmission
can be estimated by neglecting flow control from receiver. Maximum number of PDUs per
54
Cycle
0
Cycle
n+ 1
Cycle
n+ 2
Cycle
n+ 3
Cycle
63
Fig.: 5.8: FlexRay communication cycle
cycle is depend upon the cycle time. Here 5 ms cycle time is considered. The derived formula
for calculation of communication cycles is:

N umberOf F F + N umberOf CF
Number Of Cycles =
(5.8)
N umberOf P DU sP erCycle
FlexRay PDU
In FlexRay transport protocol two types of PDU available, one is short PDU and other is
long PDU. A short PDU is applied for short diagnostic request and a long PDU is used for
sending larger data for instance to flash the ECU. The name of a PDU whose position as
well as its temporal behavior is defined in the FIBEX. Figure 5.9 displays the process of
checking request data is transmitted by short PDU or long PDU. For checking the boundary
of request data, a water mark is used. If requested data is greater than water mark (112
bytes) than data is transmiited by long PDU otherwise transport protocol would be used
short PDU.
Start
Press key x
Fill send buffer
Check Request data size

Request data < water mark
Request data > water mark
Transmit long PDU
Transmit short PDU
Fig.: 5.9: check whether to apply short PDU or long PDU
55
Tester PDU
Tester PDU is specified in dynamic segment in FIBEX file. It is used for short diagnostic
request, requests with 100 bytes or less are sent via Tester PDU. One can send maximum 16
Tester PDU altogether in a one communication cycle of 5ms. As shown in figure 5.10 one
frame has total 64 cycles and every cycle contains 16 tester PDUs.
Cycle 0
T = 5ms
Tester_PDU_01
Tester_PDU_02
Tester_PDU_03
Tester_PDU_04
Tester_PDU_05
Tester_PDU_06
Tester_PDU_07
Tester_PDU_08
Tester_PDU_09
Tester_PDU_10
Tester_PDU_11
Tester_PDU_12
Tester_PDU_13
Tester_PDU_14
Tester_PDU_15
Tester_PDU_16
Cycle 1
Tester_PDU_01
Tester_PDU_02
Tester_PDU_03
Tester_PDU_04
Tester_PDU_05
Tester_PDU_06
Tester_PDU_07
Tester_PDU_08
Tester_PDU_09
Tester_PDU_10
Tester_PDU_11
Tester_PDU_12
Tester_PDU_13
Tester_PDU_14
Tester_PDU_15
Tester_PDU_16
T = 5ms
Cycle 2
Tester_PDU_01
Tester_PDU_02
Tester_PDU_03
Tester_PDU_04
Tester_PDU_05
Tester_PDU_06
Tester_PDU_07
Tester_PDU_08
Tester_PDU_09
Tester_PDU_10
Tester_PDU_11
Tester_PDU_12
Tester_PDU_13
Tester_PDU_14
Tester_PDU_15
Tester_PDU_16
Cycle 63
Tester_PDU_01
Tester_PDU_02
Tester_PDU_03
Tester_PDU_04
Tester_PDU_05
Tester_PDU_06
Tester_PDU_07
Tester_PDU_08
Tester_PDU_09
Tester_PDU_10
Tester_PDU_11
Tester_PDU_12
Tester_PDU_13
Tester_PDU_14
Tester_PDU_15
Tester_PDU_16
Communication Cycle 063

Fig.: 5.10: Tester PDU structure in coomunication cycle
Flash PDU
Flash PDU is also specified in the dynamic segment in FIBEX file. The Flash PDU name
Flash_PDU_01
Flash_PDU_02
Flash_PDU_03
Flash_PDU_04
Flash_PDU_05
Flash_PDU_06
Cycle 0
Flash_PDU_01
Flash_PDU_02
Flash_PDU_03
Flash_PDU_04
Flash_PDU_05
Flash_PDU_06
Flash_PDU_01
Flash_PDU_02
Flash_PDU_03
Flash_PDU_04
Flash_PDU_05
Flash_PDU_06
T = 5ms
Cycle 1
T = 5ms
Cycle 2
Flash_PDU_01
Flash_PDU_02
Flash_PDU_03
Flash_PDU_04
Flash_PDU_05
Flash_PDU_06
Cycle 63
Communication Cycle 063

Fig.: 5.11: Flash PDU structure in coomunication cycle
itself suggests it is benefited for flash programming, software configuration and software
56
5.5. INTERACTION OF APIS FUNCTIONS
update. With Flash PDU maximum 246 bytes are possible to send. Actual requested data
length with Single Frame Extended Flash PDU is 240 bytes (unsegmented data transmission)
and for First Frame Extended Flash PDU and Consecutive Frame Extended (segmented data
transmission) data length is 237 bytes and 241 respectively. By and large it is adopted for
the long diagnostic request. Only one Flash PDU is possible to send in one frame.
CAPL function for FlexRay PDU
frPDU < FIBEX PDU name > < PDU var> ; FlexRay PDU intialisation uses a symbolic
PDU name from the FIBEX database to create a transmission object. This can be used to
create a FlexRay PDU object. The object is then registered using the frSetSendPDU ( <PDU
object> ). A FrPDU object was created using FrPDU, it can be submitted for transmission
with this function frUpdatePDU(<PDU var>, dword flags, int updateCounter).
Theoretically FlexRay TP is able to send maximum 4GB. But with CANoe tool is not
possible to send the 4GB because it is up to now 32 bit application so it has his own
limitation. Since there is no way to store 4GB in memory. Therefore Vector has developed
the application Vflash for flashing purpose.
5.5 Interaction of APIs functions

The transport protocol module contains implementation of the ISO transport protocol and
the FlexRay transport protocol. It sends the segmented and unsegmented diagnostic messages via a bus system to ECU. Depending on the length of the diagnostic message, a
segmentation is performed. The individual segmented messages are provided with the necessary protocol control information. Also transport protocol module receives the segmented
and unsegmented messages from the ECU and verify the correct structure of the messages.
The protocol control information is removed and pass received all incoming messages to the
diagnostic module.
In the following section functions of the module as well as interaction of functions for transmission and reception of frames is described.
TX_Req_Data()
This function starts to send the first data by means of single frame or multiple frame transmission. Before it starts to transmit, it copies all send data to buffer. While saving data
to buffer it checks the requested data is in a maximum data sending capacity limit. If data
size greater than the maximum data size it throws an error.
void PrepareN_PCI(dword dwDataLength, byte bFrameType)
This function specifies the type of the frames to be created. It generates the different types
of frames like single frame, first frame, consecutive frame and flow control frame. Fort he
delivery of an unsegmented message the function PrepareN_PCI() generates the frames with
PCI. With this function API can attached the PCI parameter to the frame. Thus the API
sends the frame using function SendSF().
57
void TXConsecutiveFrame()
This function will be called when segmented transmission apply. The procedure for sending
a segmented message corresponds nearly with an unsegmented message transmission. In
segmented transmission after sending first frame using function SendFF(), flow control PDU
is received and applied contained block size and the time STmin. According tot he STmin
and block size consecutive frames would be sent. If necessary additional flow control PDUs
received and evaluated.
void TP_Handel(byte baLocalData, byte blSize)
This function checks the correct construction of the received frames. It also checks the order
of sequence numbers of consecutive frames. When TP_Handel() receives the first frame
from receiving side, it generates a flow control PDU and send using function SendFC(). And
calculates the how many numbers of consecutive frames require from the message length
parameter. Hence this function checks the body of receiving messages. RXManageIncomingFC() is called when TP_Handel() receives a flow control from the reciever and API
decides to send remaining frames or not based on flow status of the receiver. Also it manages STmin time by triggering a function RXManageIncomingSTmin().
void RXManageIncomingFC (byte bFCData[ ] )
This function manages the status of flow control that is received by the API from ECU.
A parameter bFCData[ ] contains the FC parameters FC status (clear to send, overflow,
wait), block size and minimum separation time. If the API received overflow status from
ECU then API must stop communication. In case of wait status, API has to set the timer
msFirstDataDelay() for minimum time out value of 1000 ms and variable bReadyToSend
will be set to zero. When FC is clear to send, this function increases the flow control counter
by value of one for calculating how many numbers of FCs received by API.
byte RXManageIncomingSTmin (byte bRXSTmin)
The purpose of this function is to reset the STmin according to FC from ECU. The value of
the STmin as per transport protocol specification described in the table 5.3. After resetting
the STmin, it returns the variable bRX_STmin.
byte CheckBS (byte bRXBlockSize)
This function is called after transmitting a CF PDU. It checks a block size received from the
ECU, whether it is finished or not. The aim behind the creation of this function is to wait
for FC from ECU. After sending an every CF, API checks a block size that a FC is required
or not. If FC is not received, then the API will wait for minimum time out value for that it
set the timer msTimeoutTimer( ).
TXPDUsOnBus (byte bPDU_Counter, word baPayload_data[ ])
This function is developed in order to send Tester PDUs and Flash PDUs for FlexRay
transport protocol. It decides which PDU had to apply to transmit a CF. As already
described over short PDU and long PDU in FlexRay transport protocol in section 5.4. It
checks the variable bExtendedFormat, if bExtendedFormat == 0 then this function uses
Tester PDU else transmits a Flash PDU on the bus.
58
In this section, the interaction of the functions for sending and reception of segmented and
non-segmented messages clearly represented in sequence diagrams. The figure 5.12 shows
the different functions in the transmission of an unsegmented message.
TX_Req_Data
Fill Send Buffer
PrepareN_PCI
Send Frame
Fig.: 5.12: Sequence of sending an unsegmented message
The sequence diagram in the figure 5.13 shows the sequence of sending a segmented message.
For the sake of clarity, the functions "RXManageIncomingFC()", "RXManageIncomingSTmin()" and "CheckBS()" are not shown. This process refers to the "0" size of the block
size. In a block-size size "> 0" a FC PDU is expected by the receiver between the individual
blocks.
The process of receiving a segmented message represents the sequence diagram in figure 5.14.
Upon receipt of a first frame, the function sends an FC PDU. Then the consecutive frames
are received. Depending on the block size more consecutive frames would be received and
more FC PDUs are sent.
Figure 5.14 shows the receipt of a segmented message with the block size "1". In a block size
equal to "1", the functions "TP_Handel()" and "sendFC()" are invoked more frequently in
succession (once per frame).
UDS module
The module "UDS" sends and receives diagnostic messages. Diagnostic requests are forwarded to the transport layer (module "TP"). It receives diagnostic responses from the
transport layer in the buffer "baRespData". After storing a response into buffer TP module
calls the function hex_to_ascii() for converting a hex value of response to ASCII value for
read data by identifier service. Another function UDS_NRCHandling() for error handling
and it calls after receiving a response to a request.
Interaction of UDS and TP modules
The API sends a diagnostic request through its UDS module and transfer to the transport
protocol module. Then the request would be processed by transport protocol module and
59
TX_Req_Data
Fill Send Buffer
PrepareN_PCI
Send Frame
TP Receive
On message/On frPDU
TP Handel
First Frame
Flow Control
Consecutive Frame
Check Block Size
Fig.: 5.13: Sequence of sending a segmented message
TP Receive
On message/On frPDU
TP Receive Frame
TP Handel
FF Indication
Flow Control
Flow Control
Flow Control
Fig.: 5.14: Sequence of receiving a segmented message
60
Send FC
5.6. DOCUMENTING API USING DOXYGEN
checks whether to apply segmented or unsegmented data transfer. Afterwards diagnostic

request is sent to the ECU. To receive response from the ECU same process is carried out
by transport protocol module to send the response to the UDS module. The interaction of
the individual modules during sending a diagnostic request and receiving the corresponding
response is shown in the sequence diagram (see figure 5.15).
Transport Protocol
Module
UDS Module
Call function TX_Req_Data
Call function TP_Handel
Fig.: 5.15: Interaction of the modules during sending and receiving a message
5.6 Documenting API using Doxygen

Doxygen is a powerful tool for automatic source code documentation. It can create a document from comments in source code. It supports many languages like C, C++, Java, scripting language (Python, PHP), database programming (SQL), hardware description languages
(VHDL, Verilog) and so on. While the CAPL standard does not have an API-documenting
mechanism, the only tool Doxygen has significantly become in fact a standard. Doxygen can
generate output in Hyper Text Markup Language (HTML) and latex [DOXY]. Few modifications require in doxygen setting for CAPL code after doxygen software installments.
Doxygen selects the parser to use depending on the extension of the files it parses. With
EXTENSION_MAPPING one can assign which parser to use for a given extension. Doxygen has built in mapping, and using EXTENSION_MAPPING it is possible to override or
extend the parser. The format is ext = language. For CAPL programme to make doxygen
treat .can and .cin files as C (default is CAPL) use .can = c and .cin = c. Now doxygen
can generate a document from commented CAPL .can and .cin files, functions and varibles.
Figure 5.16 displays the screenshot of HTML document of API.
Limitation: Doxygen does not recognize CAPLs own event handler functions such as on
message, on timer, on key etc.
61
5.6. DOCUMENTING API USING DOXYGEN
Fig.: 5.16: Automatically generated API documentation
Summary
CAPL API has an input through which diagnostic request/response pass as event into the
API. Showing up at output in trace window are all messages that either pass through the
program or are generated by it. Moreover, the API can react to keyboard inputs and time
events. Therefore API can be utilized as monitoring and testing of diagnostic request by
means of transport protocol behavior.
62
6 Validation
The final chapter will be focused on the validation of all module of the API. For checking
the API functionality for proper operation functional tests were performed. For this purpose manually created test data were generated, which are defined in a .can file. This data
generated the frames with the invalid PCI and unexpected frame while sending a diagnostic
request. API has been verified by manually generated test cases for transport protocol module. Likewise, the receipt of message was tested using UDS_NRCHandling() function. On
receiving negative responses, the correct operation of the error handling could be verified.
6.1 Error Handling

Errors in the message structure
If a PDU contains a PCI type which deviates from the values defined in section 2.3, then
this message must be ignored. A First Frame PDU with a First Frame Data Length (FFDL)
less than 8 must be ignored and a SingleFrame PDU with an SFDL greater than 7 must be
ignored. A Flow Control PDU with a Flow Status which deviates from the values defined
in section 2.3 causes the transfer to be canceled by the sender.
Sequence number error
A Consecutive Frame PDU with an incorrect SN causes the transfer to be canceled on the
receiver side. The message data received thus far is discarded.
Timeout error
An N_Ar timeout occurs if the data link layer on the receiver side could not send a PDU
within the time period defined in the section (FC PDU). The transfer of the message is
canceled on the sender side and the data received thus far is discarded. The receiver application is informed about the cancellation via the variable bFCInd. The Figure 6.1 displays
the timings based on a sequence diagram. An N_Bs timeout occurs if a Flow Control PDU
PDU expected by the sender has not been received within the time period (N_Bs = 1ms).
The transfer of the message is canceled on the sender side. Table 6.1 defines the cause and
action in a network layer timeout.
FC - Wait Frame error handling
If the receiver of a segmented message has sent 15 successive FC PDUs with the Wait Flow
Status and still cannot receive any new data (by sending a Flow Control PDU with Flow
Status = CTS, then it must cease sending any further Flow Control PDUs. The transfer
in progress is canceled as a result and the message data received thus far is discarded. The
receiver application is informed about the cancellation via the Data Indication.
63
6.1. ERROR HANDLING
CHAPTER 6. VALIDATION
Receiver
Sender
First Frame
N_As
N_Br
N_Bs
Flow Control
N_Ar
N_Cs
Consecutive Frame
N_Cr
N_As
Consecutive Frame
Flow Control
Consecutive Frame
Fig.: 6.1: Timer of the ISO-TP
Timeout
N_As
N_Ar
N_Bs
N_Cr
Cause
Any N_PDU not transmitted in time on the
sender side
Any N_PDU not transmitted in time on the
receiver side
Flow Control N_ PDU not received
(lost,overwritten) on the sender side or
preceding First Frame N_PDU or Consecutive
Frame N_PDU not received on the receiver
side
Consecutive Frame N_ PDU not received
(lost,overwritten) on the receiver side or preceding Flow Control Frame N_PDU not received on the sender side
Action
Abort message transmission
Abort message reception
Table 6.1: Network layer timeout error handling [ISO15765-2]
The sender is informed about the resulting NBs timeout (missing Flow Control PDU from
the receiver) and cancels its transfer as a result. The sender of the segmented message must
not monitor the number of Wait Frames received.
FC - STmin error handling
If a sender receives an FC PDU with a reserved (invalid) value, then it must utilize the
greatest permissible ST value (0x7F = 127 ms) for the remainder of the segmented message
instead of the value received.
64
6.2. TEST CASES
6.2 Test Cases

This section describes different test cases to test the implemented CAN TP and FRTP
protocol in universal UDS API. This section defines the scope of the API tests for the ISO
transport protocol in CAN as per ISO standards 15765-2 and 15765-4. Also for FlexRay
transport protocol test according to AUTOSAR FRTP.
When performing the tests, the test environment assumes the role of the tester and is
accordingly hereinafter referred to as "tester" as well and sends various ISO TP frames
as UDS requests. Since the tests are black box tests, it will not be possible to check, directly
in the electronic control unit, whether frames are correctly received. Because of this, the
responses received must be used to indirectly determine whether these frames have been
received correctly.
All tests are performed as individual API tests, i.e., there is no gateway between the simulated ECU and API being tested. The tests in this section are used to check whether the
API being tested has basic transport protocol communications properties.
6.2.1 Unexpected Frames

An unexpected arrival of a protocol data unit is either a) a PDU described in this thesis
(SF PDU, FF PDU, CF PDU or FC PDU) which is received in an unexpected sequence or
b) an unknown PDU which can not be interpreted on the basis of the definitions described
in this thesis. In case a) the unexpectedly arriving PDUs only refers to PDUs with the
same address parameters as the current send/receive process, namely PDUs for the same
point-to-point communication. Unexpectedly arriving PDUs are always ignored. Ignoring a
PDU means that the received PDU is discarded and the application is not informed about
the receipt.
API under test
sender
receiver
FF
API under test

sender
receiver API under test

sender
FF
FC
FC
FC
receiver
FF
CF
CF
CF
CF
CF
CF
CF
SF / FF
FC / CF
CF
CF
CF
CF
CF
CF
CF
CF
FC
CF
FC
FC
CF
CF
without unexpected PDU
with unexpected SF/FF PDU
with unexpected FC/CF PDU
Fig.: 6.2: API test with unexpected SF/FF/FC/CF PDU
65
6.2. TEST CASES
It can be seen from the figure 6.2 that unexpected Single Frame and First Frame are ignored
in case of half duplex communication. As far as Flow Control and Consecutive Frame PDUs
are concerned, the reception of CF is ignored during ongoing transmission while there is no
reception in progress at the sender side (sending API). Also the reception of Flow Control
is ignored because receiver can only send new control data to sender in the FC which is
expected by the sender and not in between.
Unexpected consecutive frame
The test objective is to check whether the API ignores an unexpected consecutive frame if
there are no ongoing transmission or reception operations. For checking purpose a single
consecutive frame with random data is sent to the API. The API must ignore this frame.
There should not be response from the API. Figure 6.3 shows an excerpt from the trace
window of CANoe, it represents a communication between simulated ECU and API.
Fig.: 6.3: Unexpected Consecutive Frame
Unexpected Flow Control

The objective is whether the API ignores an unexpected flow control frame if there are no
ongoing transmission or reception operations. The test criteria is the API must not receive
any ISO TP frames. So as a test input a single flow control frame is sent to the API. And
the API must ignore this frame. (see figure 6.4).
Fig.: 6.4: Unexpected Flow Control
Unexpected CF while sending

Check whether the API ignores an unexpected consecutive frame during a transmission
operation. After the API has sent the requests First Frame and during further remaining
CFs transmition , the simulated ECU sends back an unexpected consecutive frame. The API
then sends the remaing consecutive frames expected by the simulated ECU. The API must
ignore the simulated ECUs consecutive frame and continue with its transmission operation
normally. Figure 6.5 shows an unexpected CF (CF sequence number: 21) ignored by API
while it transmitting.
66
6.2. TEST CASES
Fig.: 6.5: Unexpected Consecutive Frame while sending
Unexpected Flow Control while sending

Check whether the API ignores an unexpected Flow Control frame using the same network
addres identifier during a transmission operation. As a test input the API starts transmitting
the request by sending the First Frame, then wait for the testers Flow Control frame,
and after receiving FC, API sends its Consecutive Frames. After receiving the couple of
Consecutive Frame, the simulated ECU sends a Flow Control frame. The test criteria the
API must not abort its transmission operation and it must send the request as per first
recievied FC. Figure 6.6 represents the unexpected FC received by API while sending a
block of CF, but API completes its transmission of a block.
Fig.: 6.6: Unexpected Flow Control Frame while sending
67
6.2. TEST CASES
6.2.2 Flow Control parameter test

Flow Control Flow Status test
Check whether the low nibble of the first byte in the FC frame transmitted by the electronic
control unit is coded with a value less than or equal to 2.
3X 00 00 00 00 00 00 00 Flow Control-Frame (Flow Status = CTS, OVRFLW or WAIT, X
= 0. . . 2)
Flow Control STmin parameter range test
The STmin parameter is transmitted in the third byte of the FC frame. The objective is
to check whether the ranges specified in receiving flow control byte are adhered to protocol
specification.
STmin Parameter Test 1
Check whether the API adheres to the transmission interval STmin specified by the ECU
in the FC frame. After sending the FF, the simulated ECU sends an FC frame with STmin
= 0x14 = 20 ms. The API must transmit its consecutive frames at intervals of 20 ms. Test
criteria is minimum measured interval (Tmin) between the consecutive frames must be 20
ms (see figure 6.7).
Fig.: 6.7: Flow Control frame with STmin of 20ms
STmin Parameter Test 2

Check the APIs response to a STmin parameter from the reserved range (bad STmin parameter). After transmitting the FF, the simulated ECU sends an FC frame with STmin =
0xFA (reserved, invalid range). The API must transmit its consecutive frames at intervals
of 127 ms as described in the table 5.3, i.e., set the maximum value. Figure 6.8 illustrates
the invalid STmin replaces by default value of 127 ms.
Flow Control Block Size parameter test
The Block size parameter is transmitted in the second byte of the electronic control units
FC frame. The objective is to check whether the API sets the value as per the received BS
parameter.
68
6.2. TEST CASES
Fig.: 6.8: Flow Control frame with invalid STmin
Block Size Test 1

Check whether the API adheres to the block size of 2 specified by the electronic control unit.
It can be seen from the figure 6.9 that the API received a BS of 2. Since it sends only 2
consecutive frames in a block.
Fig.: 6.9: Flow Control frame with Block Size of 2
Block Size Test 2

The simulated ECU specifies a block size of 0 for the API. The objective is to check whether
the API sends the requested data in a single block. Figure 6.10 displays the API has sent
all data in a one block because it has received a BS of zero.
Unexpected FC frame with overflow status
Check whether the API ignores an unexpected Flow Control frame with the "Overflow"
status during a transmission operation. The API starts transmitting the request (First
Frame) and after transmitting the first Consecutive Frame, the simulated ECU sends a Flow
Control frame. The API must not abort its transmission operation, and instead must send
the full request. Figure 6.11 shows after sending first CF from API, it ignores an unexpected
FC frame with an overflow status.
69
6.2. TEST CASES
Fig.: 6.10: Flow Control frame with Block Size of 0
Fig.: 6.11: Unexpected Flow Control Frame with Overflow status
Regular test
Regular FC Wait Frames after FF
The API receives 10 wait frames at intervals of 250 ms (see figure 6.12). Then a FC frame
with the CTS flow status from simulated ECU received by API. The API must resume
transmitting after receiving FC with CTS. The API must send a CF with SN = 21.
Regular Padding Test
Check whether the unused data bytes in the single frame sent by the API are padded with
0xAA, 0x55, or 0x00. The frames unused bytes must be padded with 0xAA, 0x55, or 0x00.
Figure 6.13 and 6.14 show the unused byte filled with the padding byte value 0xAA in single
frame and last CF.
70
6.2. TEST CASES
Fig.: 6.12: Test Flow Control Frame with wait status
Fig.: 6.13: Single Frame padding byte
Fig.: 6.14: Last CF Frame padding byte
71
6.2. TEST CASES
6.2.3 Timeout behaviour test

Timeout N_Bs after First Frame
Test objective to measure the N_Bs timeout period (after a FirstFrame). A simulated ECU
after receiving the FirstFrame, it delays its FlowControl frame. Test criteria is for UDS
ECUs after minimum N_Bs timeout period API must not send further request data to
simulated ECU. As shown in figure 6.15 API received FC after time out value 1ms. As a
result API has not sent further data to simulated ECU.
Fig.: 6.15: Timeout behaviour test after First Frame
Timeout N_Bs after Consecutive Frame

The aim of this test case is to measure timeout period N_Bs between an API CF and the
simulated ECUs FC frame. The block size is set to 5. After the fifth CF is received by
simulated ECU, it delays the flow control frame. Therfore after timeout period API must
not send remaining request data to ECU. Here API had received a FC at 1.53 ms hence the
API did not send the remaining data to simulated ECU (see figure 6.16).
Fig.: 6.16: Timeout behaviour test after Consecutive Frame
72
6.2. TEST CASES
6.2.4 FlexRay Transport Protocol Test

FlexRay transport protocol test must be performed for both short tester PDUs (12-byte
target/source address + data) and long flash PDUs (246-byte target/source address + data).
The extended frame type is used for long flash PDUs.
FlexRay-FC corrupt target address
The aim is to check that the API responds to Flow Control with wrong TA address. An API
is requested a segmented service. After the FF from API, FC received from the simulated
ECU with correct TA (0x4013) therefore API reacts on that. As displayed in figure 6.17
after first block a simulated ECU sent a FC with corrupt network address identifier (corrupt
TA 0x4044). In this case API must not react to send further data.
Fig.: 6.17: FlexRay-FC with wrong TA
FR-API recieved FF with wrong TA

To check that the API responds to FF with wrong TA (correct TA: 0x4013) address. An
API sent a SF and in response from the simulated ECU side it receives a FF with wrong
TA. A test criteria is API must not send a FC to the simulated ECU. Figure 6.18 shows the
API received a FF with wrong target address 0x4043. Therefore, API did not send FC.
Fig.: 6.18: FlexRay-API recieved FF with wrong TA
Summary
This section was dedicated for the results of the test cases implemented in order to check
the functionality of the ISO-TP and FlexRay TP. This part aims to represent the behaviour
of the transport protocol on API with the help of some screenshots. The verification considered separately for ISO-TP and FlrxRay TP. In the table 6.2 the modules and their tested
functionality are listed.
73
6.2. TEST CASES

Module
UDS
TP
Verified functionality
Sending and receiving of diagnostic messages
Hex to ASCII conversion for RDBI service
Negative response code checking (For error handling)
Send and receive unsegmented messages (ISO-TP/FRTP)
Send and receive segmented messagess (ISO-TP/FRTP)
Flow control parameter (Flow Status, Block Size, STmin)(ISO-TP/FRTP)
Short PDU and long PDU for FlexRay transport protocol (FRTP)
API reaction on FF and FC with wrong TA (FRTP)
Table 6.2: Verified functionalities of the individual modules
74
7 Summary and future work

This chapter summarizes the contents of this thesis and additionally it also gives a brief
overview of the future work that can be carried out in order to improve and add other
functionalities to the universal UDS API that were not addressed in the work.
7.1 Summary
This thesis deals with the concept development for universal and modular UDS API and implementation of CAN and FlexRay module. First part was a general literature survey about
the characteristics and functionality of ISO Transport Protocol and AUTOSAR FlexRay
Transport Protocol and automotive diagnostic protocol UDS. To fulfil the first functional
requirements universal and modular UDS API structure designed by making different modules for different bus architecture. Also the API structure was created according to OSI
model so it follows the layer architecture. After a general brief survey, to implement the
diagnostic service the transport protocol mechanisms of ISO-TP and AUTOSAR FlexRay
TP implementation are realized with Vector CAPL programming. The implementation was
done by constructing an experimental setup with a CANoe simulation environment tool
which allows the simulation and monitoring of bus systems and their participants. The
behavior of simulated ECU was modeled with the CAPL programming language. The diagnose protocol UDS module was concluded with a diagnostic service Read Data By Identifier
(0x22).
After fulfilling the functional requirements, an API was tested by creating various test cases.
The TP protocol module was firstly tested with different unexpected frame test cases. After
that some regular test cases were performed for example unexpected flow control while
sending. Then most important test case implemented to test the flow control parameters
that contains the block size test, STmin test and FC status test. Also timeout behavior
tested to ensure the function of the transport protocol even under unfavorable conditions
for example timeout behavior after consecutive frame. FlexRay TP has the same properties
but FlexRay has target address and source address hence tested API whether it received
FF or FC with wrong target address. Last task was to generate an automated API source
code documentation using Doxygen 1.8.9.1 tool. It describes all implemented function with
their parameter description. Therefore it is easy to understand the source code whoever will
make further improvement.
In a nutshell, this thesis contains the complete explanation of structuring an entire universal
UDS API and implementation of this API. It also illustrates the definition to run the already
implemented API on the target control unit. Additionally, an API was tested as per specified
75
7.2. FUTURE WORK
CHAPTER 7. SUMMARY AND FUTURE WORK
test cases of transport protocol. This developed API can be used on CAN and FlexRay
control units. To transmit a diagnostic request on FlexRay or other bus system for example
LIN, Ethernet is not easy just like CAN bus. With this work the diagnostic request can
be performed now without software gateway. Still in the future, there are lots of new
features can be added and lots of changes are required for improvement and optimization
of CAPL program. The main task of this thesis was to develop a concept for universal
and modular API and implementation of it for one module was successfully achieved. Last,
but by no means least, all defined functions were documented using automated source code
documentation tool Doxygen.
7.2 Future Work

Since this research area is new, existing state of the art is limited and the possibility of
improvement is immense. This section mainly aims at giving an outlook into the future,
discussing various possibilities of how the project can progress and what other functionalities
can be integrated into the present application scenario. This thesis is the basis for the
implementation of the transport protocol and diagnostic protocol. The diagnostic module
(UDS) cannot read ODX file through CAPL programing. Since the first task to improvement
API is implementation of ODX file reader. Recently, Ethernet based DoIP was implemented
to the vehicle diagnostic system. The beginning of DoIP protocol not only decreases the
complexity of the network but also reduces the update time for ECU flashing. As a result
further development would be Diagnose over Internet Protocol (DoIP) for Ethernet bus and
LIN Transport Protocol in transport protocol module implementation. The UDS module
just contains Read Data By Identifier (RDBI) service implementation. Therefore extension
of the UDS module is implementation of additional important services for example RDTC,
CDTC, Security Access using Seed and Key principle, Diagnostic Session Control and ECU
Reset. This leads an extension of the thesis and the generic approach can be accomplished
by creating different modules for LIN and Ethernet. As a consequence that will expands the
modular UDS API.
For working on the above mentioned research possibilities my thesis work can be taken as a
starting point and as a reference document for others.
76
List of abbreviations
Abbreviations
API
ASAM
BS
CAN
CAPL
DTC
ECU
FC
FF
FIBEX
FS
KWP 2000
LIN
MOST
NRC
ODX
OSI
PCI
PDU
RDBI
RDTC
SID
SF
STmin
TP
UDS
XML
Application Programming Interface

Association for Standardization in Automation
and Measuring Systems
Block Size
Controller Area Network
Communication Access Programming Language
Diagnostics Trouble Code
Electronic Control Unit
Flow Control
First Frame
Field Bus EXchange Format
Flow Status
Key Word Protocol 2000
Local Interconnect Network
Media Oriented System Transport
Negative Response Code
Open Diagnostic Data Exchange
Open System Interconnection
Protocol Control Information
Protocol Data Unit
Read Data By Identifier
Read Diagnostics Trouble Code
Service Identifier
Single Frame
Minimum Separation Time
Transport Protocol
Unified Diagnostic Services
Extensible Markup Language
77
List of Figures
1.1
1.2
Software gateway routing the diagnostics request between CAN bus and target
bus (FlexRay) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Time delay occurs during gateway transfers frame . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
Modern Vehicle architecture [ZiSch] . . . . . . . . . . . . . . . . .

Bit arbitration [ZiSch] . . . . . . . . . . . . . . . . . . . . . . . .
CAN Frame structure [ZiSch] [SPAS] . . . . . . . . . . . . . . . .
ISO-TP message structure [ZiSch] . . . . . . . . . . . . . . . . . .
ISO-TP single frame data transmission [VWTP] . . . . . . . . . .
ISO-TP multiple frame transmission [VWTP] . . . . . . . . . . .
FlexRay Logo [FLXC] . . . . . . . . . . . . . . . . . . . . . . . .
FlexRay TDMA Structure [VFPR] . . . . . . . . . . . . . . . . .
Static Segment [MaRa] . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Segment [MaRa] . . . . . . . . . . . . . . . . . . . . . .
Flexray Static and Dynamic Segments with Media Access [IXXF]
FlexRay transport protocol [ZiSch] . . . . . . . . . . . . . . . . .
PDU format of FlexffRay TP [ZiSch] . . . . . . . . . . . . . . . .
Format of the PCI fields [ZiSch] . . . . . . . . . . . . . . . . . . .
Off-board communication [EMOT] . . . . . . . . . . . . . . . . .
Diagnostics communication principle [EMOT] . . . . . . . . . . .
Physical addressing mode [VWUDS] . . . . . . . . . . . . . . . .
Functional addressing mode [VWUDS] . . . . . . . . . . . . . . .
Process chain with ODX [ASAM] . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
8
10
11
12
13
14
15
16
16
17
17
18
19
20
21
21
27
3.1
3.2
3.3
3.4
Current Situation . . . . . . . . . . . . . . . .
FlexRay ISO-TP PDU for diagnose [TPLAH]
Example CAN-FlexRay Routing [TPLAH] . .
Example FlexRay-CAN Routing [TPLAH] . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
30
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Diagnostic communication from the perspective of the OSI

Protocol stack according to ISO/OSI layer model [EMOT]
Desired Situation . . . . . . . . . . . . . . . . . . . . . . .
Current Situation . . . . . . . . . . . . . . . . . . . . . . .
Modular design of the universal UDS API . . . . . . . . .
Transport protocol module process . . . . . . . . . . . . .
Process of performing UDS service at application layer . .
Access to the bus interface . . . . . . . . . . . . . . . . . .
concept realization with Read DTC information service .
[MaSu]
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
34
35
36
38
39
40
78
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
moedl
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2
3
List of Figures
List of Figures
4.10 Block diagram of UDS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
CANoe configuration windows . . . . . . . . . . . . . . . . . . . . . . . . . . .

CAPL Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process flow of sending ISOTP message . . . . . . . . . . . . . . . . . . . . .
Flowchart of checking conseutive frame and sending flow control frame function
FlexRay simulation setup in CANoe . . . . . . . . . . . . . . . . . . . . . . .
FlexRay communication cycle . . . . . . . . . . . . . . . . . . . . . . . . . . .
check whether to apply short PDU or long PDU . . . . . . . . . . . . . . . . .
Tester PDU structure in coomunication cycle . . . . . . . . . . . . . . . . . .
Flash PDU structure in coomunication cycle . . . . . . . . . . . . . . . . . . .
Sequence of sending an unsegmented message . . . . . . . . . . . . . . . . . .
Sequence of sending a segmented message . . . . . . . . . . . . . . . . . . . .
Sequence of receiving a segmented message . . . . . . . . . . . . . . . . . . .
Interaction of the modules during sending and receiving a message . . . . . .
Automatically generated API documentation . . . . . . . . . . . . . . . . . .
43
44
47
47
52
53
54
55
55
56
56
59
60
60
61
62
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
Timer of the ISO-TP . . . . . . . . . . . . . . . . . . .

API test with unexpected SF/FF/FC/CF PDU . . . .
Unexpected Consecutive Frame . . . . . . . . . . . . .
Unexpected Flow Control . . . . . . . . . . . . . . . .
Unexpected Consecutive Frame while sending . . . . .
Unexpected Flow Control Frame while sending . . . .
Flow Control frame with STmin of 20ms . . . . . . . .
Flow Control frame with invalid STmin . . . . . . . .
Flow Control frame with Block Size of 2 . . . . . . . .
Flow Control frame with Block Size of 0 . . . . . . . .
Unexpected Flow Control Frame with Overflow status
Test Flow Control Frame with wait status . . . . . . .
Single Frame padding byte . . . . . . . . . . . . . . . .
Last CF Frame padding byte . . . . . . . . . . . . . .
Timeout behaviour test after First Frame . . . . . . .
Timeout behaviour test after Consecutive Frame . . .
FlexRay-FC with wrong TA . . . . . . . . . . . . . .
FlexRay-API recieved FF with wrong TA . . . . . . .
64
65
66
66
67
67
68
69
69
70
70
71
71
71
72
72
73
73
79
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List of Tables
2.1
2.2
2.3
2.4
2.5
2.6
2.7
List of diagnostics services of UDS [ISO14229] . . . . . . . . . . . . . .

Request message of the Read Data By Identifier [ISO14229] . . . . . .
Positive response message of the Read Data By Identifier [ISO14229] .
Negative response message of the Read Data By Identifier [ISO14229] .
Request message of the Read DTC [ISO14229] . . . . . . . . . . . . . .
Response message of the Read DTC [ISO14229] . . . . . . . . . . . . .
List of negative response code [ISO14229] . . . . . . . . . . . . . . . .
3.1
Advantage and disadvantage of software gateway . . . . . . . . . . . . . . . . 31
4.1
Vector hardwares for bus interface . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1
5.2
5.3
Structure of a Flow Control PDU [VWTP] . . . . . . . . . . . . . . . . . . . . 48

Meaning of the Flow Status parameter [VWTP] . . . . . . . . . . . . . . . . . 48
Value of the Separation Time parameter [VWTP] . . . . . . . . . . . . . . . . 49
6.1
6.2
Network layer timeout error handling [ISO15765-2] . . . . . . . . . . . . . . . 64

Verified functionalities of the individual modules . . . . . . . . . . . . . . . . 74
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
24
25
25
26
Bibliography
[ASAM] ASAM e.V. (04. 03. 2005)ASAM MCD-2D (ODX) Data Model Specification,
Version 2.0.1
[ASOF] Technical Article,Vehicular Diagnostics From Nuisance to Necessity ,
http://automotive.softing.com/fileadmin/soffiles/pdf/de/ae/
Available:
articles/2011/Technical_article_AUTOMOTIV_2011-5_Vehicular_Diagnostics_
From_Nuisance_to_Necessity_1_2.pdf
[EMOT] Transport-Diagnoseprotokol Available: http://www.emotive.de/documents/
WebcastsProtected/Transport-Diagnoseprotokolle.pdf
[FLXC] FlexRay Consortium www.flexray.com
[VWUDS] Volkswagen AG VW 80124 - Unified Diagnostic Services Protocol,Application Layer and Implementation,2010, Version 1.10.
[VWTP] Volkswagen AG (18-11-2010) ISO Transport Protocol Interdisciplinary Performance Specification LAH.5G0.042.B, 2010, Version 1.1
[ISOTP] ISO TP Test Specification as per ISO 15765-2 and ISO 15765-4 VW internal
document
[TPLAH] Gerhard Bauersachs, Tobias Ammler ISO Transportprotokoll, 2007.
[VFPR] Vector Group, FlexRay Protocol Reference Chart, Version 2.0, 2008.
[IXXF] FlexRay Introduction, Available: www.ixxat.com/introduction_flexray_en.
html
[ZiSch] Zimmermann W., Schmidgall R., Bussysteme in der Fahrzeugtechnik. Protokolle, Standards und Softwarearchitektur,Fifth Addition,Springer Vieweg Verlag,
2014.
[MaRa] Mathias Rausch FlexRay, Grundlagen, Funktionsweise, Anwendung,Hanser
Verlag , 2008.
[ISO14229] ISO 14229, Road vehicles - Unified Diagnostics Services (UDS)- Specification and requirements Second edition 2006.
[ISO15765-2] ISO 15765-2 (15- 11- 2011), Road Vehicles - Diagnostic communication
over Controller Area Network Part 2: Transport protocol and network layer services,
Second Edition, International Organization for Standardization.
81
Bibliography
Bibliography
[ISO15765-3] ISO 15765-3 (15- 10-2004) Road vehicles - Diagnostics on Controller

Area Network Part 3: Implementation of Unified Diagnostic Services (UDS on CAN),
First Edition,International Organization for Standardization.
[MaSu] Christoph Marscholik, Peter Subke, Road vehicles-Diagnostics communication,
VDE VERLAG, 2008.
[SPAS] Prof.Dr.-Ing. Alejandro Masrur, Software Platforms for Automotive Systems,
Lecture:10 The CAN Bus, Chemnitz University of Technology, 2014.
[AESR] Ralf Schmidgall, Automotive embedded systems software reprogramming, School
of Engineering and Design, Brunel University, May 2012.
[TUC] Dr. Mirko Caspar, Norbert Englisch, Automotive Software Engineering, Unit: 5
Testing, Computer Engineering, Chemnitz University of Technology, 2014.
[SUNX] Sun Xiangwen, Entwicklung und Integration von User-Code zur Realisierung
von Diagnosediensten auf dem TTX Datalogger, Chemnitz University of Technology,
Jun 2014.
[DOXY] Doxygen manual, Available: http://www.stack.nl/~dimitri/doxygen/
[Bosch] BOSCH: Test Equipment Available: http://www.bosch-diagnostics-oes.
de/diagnostics_oes/de/loesungen/testequipment/diagnose/mts6516.htm
[BeMa] Berner und Mattner: iDEX-Flexible Diagnoselsung fr die Fahrzeuginbetriebnahme. Available: http://www.berner-mattner.com/de/berner-mattner-home/
leistungen/idex.html
[Soft] Softing Automotive Electronics GmbH: VAS 5163 Datenblatt, Softing Automotive
Electronics GmbH
[Konr] Prof. Dr.-Ing. Konrad Reif: Dieselmotor-Management Systeme, Komponenten,
Steuerung und Regelung, Vieweg+Teubner Verlag, 2012, p. 472-491. e- ISBN: 978-38348-2179-9
[UDSP] Panuwat Assawinjaipetch , Michael Heeg , Daniel Gross , Stefan Kowalewski,
Unified Diagnostic Services Protocol Implementation in an Engine Control Unit.
82

Master Thesis Ketan Bavalia

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Master Thesis Ketan Bavalia

Caricato da

Copyright:

Formati disponibili

Technische Universitt Chemnitz

Faculty of Computer Science

CONCEPT AND IMPLEMENTATION OF A UNIVERSAL

Masters of Science in Automotive Software Engineering

Prof. Dr. Wolfram Hardt

Dr. Ariane Heller

MSc. Stefan Bogner

Ingolstadt, June 11, 2015

3 State of the art

7 Summary and future work

1.2. PROBLEM STATEMENT

ECU functions, of flash functions or in Hardware-in-the-Loop (HiL) and in the integration

1.2 Problem Statement

1.3. STRUCTURE OF MASTER THESIS

Fig.: 1.2: Time delay occurs during gateway transfers frame

1.3 Structure of master thesis

1.3. STRUCTURE OF MASTER THESIS

2.1 Vehicle networking

2.1. VEHICLE NETWORKING

Fig.: 2.1: Modern Vehicle architecture [ZiSch]

2.1.1 CAN Control Area Network

2.1. VEHICLE NETWORKING

Error detection and signaling

2.1. VEHICLE NETWORKING

11 bit Message Identifier

Losses the arbitration

Fig.: 2.2: Bit arbitration [ZiSch]

Fig.: 2.3: CAN Frame structure [ZiSch] [SPAS]

2.1. VEHICLE NETWORKING

2.1.2 ISO-Transport Protocol

2.1. VEHICLE NETWORKING

Data (Diagnostic Message)

Data (Diagnostic Message)

07 Data Bytes (last CF<7 Bytes)

Data (Diagnostic Message)

Fig.: 2.4: ISO-TP message structure [ZiSch]

ISO-TP Message Structure

2.1. VEHICLE NETWORKING

Fig.: 2.5: ISO-TP single frame data transmission [VWTP]

2.1. VEHICLE NETWORKING

Fig.: 2.6: ISO-TP multiple frame transmission [VWTP]

2.1. VEHICLE NETWORKING

2.1. VEHICLE NETWORKING

static dynamic SW NIT

static dynamic SW NIT

static dynamic SW NIT

static dynamic SW NIT

trailer DTS CID

Fig.: 2.8: FlexRay TDMA Structure [VFPR]

2.1. VEHICLE NETWORKING

Network Idle Time

Fig.: 2.9: Static Segment [MaRa]

2.1. VEHICLE NETWORKING

Network Idle Time

Fig.: 2.10: Dynamic Segment [MaRa]

2.1. VEHICLE NETWORKING

Fig.: 2.12: FlexRay transport protocol [ZiSch]

Max 254 Byte

Fig.: 2.13: PDU format of FlexffRay TP [ZiSch]

DL- Data Length

Fig.: 2.14: Format of the PCI fields [ZiSch]

2.2.1 Overview on automotive diagnosis

1. High speed (High speed CAN, FlexRay)

Fig.: 2.15: Off-board communication [EMOT]