Documente Academic
Documente Profesional
Documente Cultură
Master Thesis
Professor
Professor
Supervisor 1
Supervisor 2
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.
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 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
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
CHAPTER 1. INTRODUCTION
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.
CHAPTER 1. INTRODUCTION
CHAPTER 1. INTRODUCTION
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.
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
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.
CHAPTER 2. BASICS
Start Bit
CHAPTER 2. BASICS
00
11
11
11
00
11
00
00
ECU1
11
Collision
00
ECU2
Signal on
the bus
0 Dominant Level
1 Recessive Level
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
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]
Single
Frame
CHAPTER 2. BASICS
Bit 74
Bit 30
0x00
DL
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
1 Byte PCI
Flow Control
Frame
Bit 74
Bit 30
Bit 70
0x03
FS
BS
Bit 70
STMin
3 Byte PCI
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.
11
CHAPTER 2. BASICS
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]
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
gdMinislotActionPointOffset
gdOffsetCorrection
Start
variable Duration
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
Frames with a
fixed ID
Macrotick
MT
MT
MT
Microtick
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
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
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
TA
Address Info
SA
1.5 Byte
Data Bytes
PCI
Protocol Control Info
Payload
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
DL7....0
DL11.0
DL31....0
BS
BS- Block Size
ST- Separation Time
STmin
SN- Sequence Number
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.
18
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
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
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
(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)
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.
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
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
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
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
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
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
0x59
0x02
XX
XX
XX
XX
XX
XX
XX
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]
26
2.2. DIAGNOSTIC
CHAPTER 2. BASICS
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
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
CANoe
Diagnose
Service
CAN
FlexRay
Software
Gateway
ECU
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
Target
10
11
12
Source
ISO-TP Frame
0x718
Gateway
FlexRay
PDU
ISO- TP Fra me
Target: 0x718 - 0x700 = 0x18 / Source = 0x10
0x18
0x10
ISO- TP Fra me
FlexRay
PDU
0x10
0x18
Gateway
CAN Message
ISO- TP Fra me
ISO- TP Fra me
30
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
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.
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
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
Application Layer
Layer 7
Diagnostic Protocol
Transport Protocol
Transport Layer
Layer 4
Transport Protocol
Bus System
Bus System
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
CHAPTER 4. CONCEPT
UDS
ISO-TP
ISO-TP/FRTP/DoIP
CAN
CAN
FlexRay
LIN
Ethernet
CAN
CAN <-> FR GW
FlexRay
ECU
ECU
ECU
ECU
ECU
34
Tester
CHAPTER 4. CONCEPT
CAPL
API
ODX/PDX
Import
UDS Protocol
Application Layer
Transport Protocol
Transport Layer
CAN
Disturbance
FlexRay
Disturbance
Physical Layer
LIN
Disturbance
Ethernet
Disturbance
BUS Interface
Communication Bus
ECU
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
22 F1 87 XX XX XX XX
CAN
0x715
03 22 F1 87 XX XX XX XX
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
36
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
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
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
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
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
Bus interfaces hardware are also provide by different manufacturer such as ETAS, PEAK
System, Softing and so on.
39
CHAPTER 4. CONCEPT
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
UDS
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
Read Data By
Identifier
CHAPTER 4. CONCEPT
Read DTC
Information
Clear Diagnostic
Information
UDS API
Identifier
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.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
CHAPTER 5. IMPLEMENTATION
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.
43
CHAPTER 5. IMPLEMENTATION
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).
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
CHAPTER 5. IMPLEMENTATION
45
CHAPTER 5. IMPLEMENTATION
46
CHAPTER 5. IMPLEMENTATION
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
FC PCI Byte1
0 0 1 1 FS
Byte2
BS
Byte3
STmin
CHAPTER 5. IMPLEMENTATION
Byte4
0xAA
Byte5
0xAA
Byte6
0xAA
Byte7
0xAA
Byte8
0xAA
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
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
CHAPTER 5. IMPLEMENTATION
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
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)
49
CHAPTER 5. IMPLEMENTATION
(5.4)
(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
CHAPTER 5. IMPLEMENTATION
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
CHAPTER 5. IMPLEMENTATION
Start
Press key T
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
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
CHAPTER 5. IMPLEMENTATION
Start
No
Check if frame
is expected
Yes
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
11
12
13
CHAPTER 5. IMPLEMENTATION
54
CHAPTER 5. IMPLEMENTATION
Cycle
0
Cycle
n+ 1
Cycle
n+ 2
Cycle
n+ 3
Cycle
63
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
55
CHAPTER 5. IMPLEMENTATION
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
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
itself suggests it is benefited for flash programming, software configuration and software
56
CHAPTER 5. IMPLEMENTATION
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.
57
CHAPTER 5. IMPLEMENTATION
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
CHAPTER 5. IMPLEMENTATION
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
PrepareN_PCI
Send Frame
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
PrepareN_PCI
CHAPTER 5. IMPLEMENTATION
Send Frame
TP Receive
On message/On frPDU
TP Handel
First Frame
Flow Control
Consecutive Frame
TP Receive
On message/On frPDU
TP Receive Frame
TP Handel
FF Indication
Flow Control
Flow Control
Flow Control
60
Send FC
CHAPTER 5. IMPLEMENTATION
UDS Module
Fig.: 5.15: Interaction of the modules during sending and receiving a message
61
CHAPTER 5. IMPLEMENTATION
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.
63
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
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
Abort message transmission
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
CHAPTER 6. VALIDATION
receiver
FF
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
65
CHAPTER 6. VALIDATION
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.
66
CHAPTER 6. VALIDATION
67
CHAPTER 6. VALIDATION
68
CHAPTER 6. VALIDATION
69
CHAPTER 6. VALIDATION
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
CHAPTER 6. VALIDATION
71
CHAPTER 6. VALIDATION
72
CHAPTER 6. VALIDATION
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
TP
CHAPTER 6. VALIDATION
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.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
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.
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
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
[MaSu]
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
34
35
36
38
39
40
78
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
moedl
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2
3
List of Figures
List of Figures
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
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
3.1
4.1
5.1
5.2
5.3
6.1
6.2
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
82