Unified Diagnostic Services

White Paper – WP1903

Unified Diagnoistic Services

White Paper
Unified Diagnostic Services

CONTACT Softing Automotive Electronics GmbH

Richard-Reitzner-Allee 6
85540 Haar – Germany
E-mail: info.automotive @ softing.com
Internet: www.automotive.softing.com

Exclusion of Liability The information provided in this White Paper corresponds to the state of art when
going to press and is provided to the best of our knowledge. We will not accept any
warranty claims arising from the information provided in this paper, especially
warranties for quality and durability pursuant to section 443 of the German Civil
Code. We reserve the right to make improvements and additions to and to include
new findings in this White Paper without giving advanced notice.
Errors and omissions reserved. We provide this White Paper to our customerss and
prospective clients free of charge.
Reprinting and reproducing this White Paper and making it available electronically,
even in the form of excerpts, is only permissible with our written consent.
All rights reserved.
Legal Notice Softing Automotive Electronics GmbH
Managing Directors: Armin Baumann, Oliver Fieth, Dr. Wolfgang Trier

Table of Contents

1. What is diagnostic communication? ................................................................................... 2

2. Diagnostic communication in the OSI Model ..................................................................... 3
3. OSI Model Application Layer Services and SIDs .................................................................. 3
4. Data Parameters and Sub-function Bytes ........................................................................... 4
5. Negative Responses and NRCs ............................................................................................ 5
6. UDS on CAN > DoCAN ......................................................................................................... 5
7. UDS on IP > DoIP ................................................................................................................. 6
8. TST Technology ................................................................................................................... 6

References

http://profiles.sae.org/79697328210/

© Softing Automotive - White Paper 1903 Page 1

White Paper
Unified Diagnostic Services

1. What is diagnostic communication?

Diagnostic communication is communication between a vehicle or mobile machine and

external test equipment (tester). Actually, the communication does not take place between
the tester and the vehicle or machine, but at a certain point in time, between the tester and
one specifically selected electronic control unit (ECU).

Figure WP1303-01: Diagnostic service requests and responses

For the purpose of diagnostic communication, the tester (TST) sends a diagnostic service
request to the ECU and receives the diagnostic service response from the ECU (Figure
WP1303-01).

Figure WP1903-02: Components of a diagnostic communication System

© Softing Automotive - White Paper 1903 Page 2

White Paper
Unified Diagnostic Services

To do so, tester (TST) and vehicle (ECU) must be connected to each other by a Vehicle
Communication Interface (VCI). Figure WP1303-02 shows the components of a generic
diagnostic communication system.

2. Diagnostic communication in the OSI Model

The OSI Model structures data communication systems in seven layers. In the context of this
White Paper, “UDS” is an OSI Model application layer protocol. “CAN” is specified as OSI
model physical and data link layer protocols. The concatenations “UDS on CAN” and “UDS on
IP” are diagnostic protocol stacks that consist of several, independently specified OSI model
layers. Other examples are “KWP on K-Line” or “OBD on CAN”. Figure WP1903-03 shows
how the diagnostic communication protocol stacks “UDS on CAN” and “UDS on IP” are
mapped to the OSI Model.

Figure WP1903-03: UDS on CAN and UDS on IP protocol stacks

3. OSI Model Application Layer Services and SIDs

Table WP1903-01 lists the 27 Unified Diagnostic Service (UDS) requests as they are specified
in ISO 14229-1 (2018). Each service request comes with a uniquely assigned service identifier
(SID), such as 0x10 = diagnostic session control request, 0x22 = read data by identifier
request or 0x3E = tester present request. Each request has an assigned positive response,
whereas the SID of a response can be calculated by adding 0x40 to the SID of the request.
Table WP1903-02 shows examples. The SID of a negative response is always 0x7F.

© Softing Automotive - White Paper 1903 Page 3

White Paper
Unified Diagnostic Services

Table WP1903-01: Services and Request SIDs according to ISO 14229-1 (2018)

Table WP1903-02: Examples of request and response SIDs

Request SID Service Pos. Response

SID
0x10 Diagnostic session control 0x50
0x22 Read data by identifier 0x62
0x31 Routine control 0x71
0x85 Control DTC settings 0xC5

4. Data Parameters and Sub-function Bytes

UDS requests and responses can be parameterized by sub-function bytes and/or data
parameters. Data parameters are identified by Data Identifier (DID). Table 1903-03 shows
some selected DID examples.

© Softing Automotive - White Paper 1903 Page 4

White Paper
Unified Diagnostic Services

Table 1903-03: Examples of Data Identifier (DID) - Examples

DID Description
0xF180 Boot software identification
0xF18C ECU serial number
0xF190 Vehicle Identification Number (VIN)

5. Negative Responses and NRCs

If an ECU is not able to support a request, for example if it cannot deliver the requested data
(0x22 = read data by identifier) or cannot process a requested action (0x11 = ECU reset) – for
what reason ever – the ECU will send a negative response with the negative response SID
0x7F.
The negative response consists of three bytes: The first byte is the SID of the negative
response (0x7F), the second one is the SID of the denied request. The third byte is a
parameter named negative response code (NRC). The NRC contains information, why the
ECU is not sending a positive response. Typical values of NRCs are listed in Table WP1903-04.

Table 1903-04: Negative Response Codes (NRC) - Examples

NRC Comment
0x10 General reject
0x11 Service not supported
0x12 Sub-function not supported
0x22 Conditions not correct

6. UDS on CAN > DoCAN

CAN is specified in ISO 11898 and not part of this White Paper.
DoCAN is short for “Diagnostics on CAN” and specified in ISO 15765. It describes, how ISO
14229 services are transferred using the physical and data link layers of CAN.
A specific “problem” of CAN is the limited number of data bytes that fit in a single CAN frame.
The Vehicle Identification Number, for example, consists of 17 bytes and does not fit in a
single CAN message frame.
The request to read the VIN reads
0x[22,F1,90].
The positive response could be
0x[62,F1,90,35,48,44,31,47,56,34,31,39,38,4B,33,32,36,32,32,35], whereas the 17 data bytes

© Softing Automotive - White Paper 1903 Page 5

White Paper
Unified Diagnostic Services

after the 0x [62,F1,90...] represent the VIN of a Harley Davidson motorcycle type FXWG MY
1981.

Data blocks that do not fit in a single CAN frame must be segmented and sent with several,
consecutive CAN frames. The description of how that works is colloquially named ISO TP,
whereas TP is short for transport protocol. ISO TP for UDS on CAN is specified in ISO 15765-2.

7. UDS on IP > DoIP

Ethernet is specified in IEEE 802.3 and not part of this White Paper.
DoIP is specified in ISO 13400 and describes, how ISO 14229 services are transferred using
the Internet Protocol IP and IEEE 802 Ethernet.

8. TST Technology

Figure 1903-04 shows the software components of a diagnostic tester. ODX is short for the
Open Diagnostic Data Exchange format and OTX for the Open Test Sequence exchange
format.
The Smart Diagnostic Engine (SDE) processes service requests and responses using the ODX
data that mainly contains the specification of the diagnostic communication protocol stack
and computational methods to translate hex coded diagnostic data into meaningful
information. The OTX data base contains scripts that describe diagnostic sequences, e.g. for
guided fault finding or flash reprogramming of a control unit.

© Softing Automotive - White Paper 1903 Page 6

White Paper
Unified Diagnostic Services

Figure WP1903-04: Software components of a diagnostic tester

The application can be software on a WIN-based PC or an APP on an Android-/iOS- based

smart device.
The VCI and its firmware are connected to the SDE via one of the interfaces D-PDU API,
RP1210 or SAE J2534, whereby a VCI is not necessary anymore if a regular PC with a RJ45
Ethernet port and UDS on IP are employed.

Amendment Log

Version Date Author Description / Comment / Modification

01 2019-06-23 Subke Draft

https://www.sae.org/publications/books/content/r-474/

© Softing Automotive - White Paper 1903 Page 7