UDS A DEEP DIVE TO UNIFIED DIAGNOSTIC SERVICES

ISO 14230-3 (KWP2000) & ISO 15765-3 (Diagnostic Communication

over Controller Area Network (DoCAN)).

Ref:
https://www.youtube.com/playlist?list=PLYLyT1P5haUepvTlIk9ah_H
ff_tRml3VE

MISSED :
3. To understand the UDS over ISO layer
4. To implement Code optimization techniques in CAPL scripting
5. To work on the cdd, pdx file system

User → UDS (application layer) → Core comm. Protocols → ECU

Why was it created?

As a result, multiple parties with diverse backgrounds need to communicate in
the same language, which is why a unified diagnostic service was designed to
address various interests throughout the ECU's life cycle.

Where UDS is used?

UDS works only with underlying other data transfer protocol

Car manufacturer / vehicleparts suppliers use UDS for
1. read the data written inside the memory of the ECU
2. control the input and output for the ECU
3. choose the correct variant for the software to be installed
4. Test & debug the soft
5. During manufacturing, suppliers want one simple method for
flashing software and validating basic functionality.

UDS over CAN

PROB: toyota software glitch

SAEE→ created common lang/ tool used to talk to various automotive
architecture → UDS
UDS→ lang used to talk to any automotive architecture irrespective of
the communication protocol used
● To some extent it can diagnose the problem & rectify by itself.
● UDS Std. id: ISO 14229-1
● Even allows us to use our own lang syntax in the UDS protocol.
○ Diff. lang use UDS protocol eg: diff for hyundai, tata
UDS mainly used to read the data from the car.
● The maximum size of message supported within UDS is up to 8 bytes.
For exchanging messages exceeding 8-bytes, the UDS protocol uses ISO
15765-2 layer, an international standard for transfer of data packets over a
CANBus.
● DoIP facilitates diagnostics related communication between external test
equipment and automotive control units (ECU) using IP, TCP and UDP.
What is UDS??
● ISO technical Committee and the SAE Committee created a standard that
identifies and runs distinct services and sub functions by asking these
service commands from any computer system and receiving the results.
So that the ECUs may also tell the human what the problem is inside so
that it can be readily fixed.
UDS TYPES:
● Off board UDS services → external tools used to diagnose using the OBD
port . data read from the gateway ECU node.
● On board UDS services → software itself diagnose and resolves the prob
○ Using MIL → malfunction identification lamp

UDS OSI model:

OBD methodology:
Client → tester
ECU → server

Response types:
● +ve response → response got from the server
● -ve response → no response from the server to the OBD
Communication → hexadecimal format for the lang

Various functions of the ECU:

● Diagnostic and communication management.
● Data Transmission
● Stored Data Transmission
 ● Input/output Control
● Remote activation of routine
● Upload/Download

Request data frame format:

SID (1byte) Sub function DID (2 byte) Data record fields

(1byte) (n byte)

SID → 1 byte Every service has a predef id. Eg: to read service there
service (mandatory is a separate SID. eg. to reset a function.
identifier field)

Sub 1Byte (non Sub category of the SID eg. hard reset
function mandatory
of the SID field)

DID → 2 bytes(non eg. To read a temperature value(specify the data to be

data mandatory accessed )
identifier field)

Data N bytes(non We will specify the timing at which we want the

record mandatory response.
fields field) In some app. We can specify the memory to be stored
in this field so that it can be used in some other format.
Like cache. The values are stored in the hexadecimal.

Eg. I want a response of the data in 1ms. But due to

practical I may get the data before/after 1ms, which will
be recorded in this data record field.

PDU, PCI, SDU

● Here the UDS is put in the CAN data field, it is known as UDS over CAN.
Similar for the flexray, ethernet etc.
● Software adds this data field of comm. Protocol auto.
RESPONSE:
+ve response → SID field format → the SID + 0x40
Eg: SID→ 10, 40 is for the +ve id.
For SID → 10; the +ve SID for the responses → 10 + 40 → SID⇒50
Why 40??
● The decimal value of the 50 → 01010000 , the seventh bit is high, makes the
client know that their request is successfully processed.
—-------------------------------------—------
-ve response→ 3bytes
DATA format:

03 (PCI value always) 7F SID req Reason of the -ve response

ECU has a primary and secondary bootloader. The modified code can be flashed to
the secondary bootloader using the OBD port as there is no way to flash the code
using the debugging port in the ECU.

DiagnosticSessionControl (online notes)(0x10)

Sessions were created to keep the critical diagnostic data to be not available at all
the time. The certain secured data are available only with secured access.

Primary session service:

1. Default
2. Non default session
● Programming
● Extended diagnostic session
The diagnostic session, in short, is a state in which the ECU determines what is available for
diagnosis

0x01 default session: which is the default state when the ECU is in the normal running
state
0x03 extended session: which is the state where all diagnostic services are available (
doesn’t mean accessible yet)

0x02 programming session: which is the state where the ECU switches from application
software to its bootloader software where the client can update the application with a new
version and fix.

● The diagnostic tester (client) can send physical or functional UDS requests.

Functional IDE → like network IDE

Physical IDE → ID given to each ECU

A functional request is a type of broadcast message that is issued to all

CAN-based ECUs.
Only a single ECU on the network receives Physical UDS queries.

diagnostic engineer → send the diagnostic request (Physical addressing),

receive the diagnostic data, and solve the problem directly from that ECU.

If defects
are not detected → send a request (Functional addressing) to all the
ECUs in the car, read all of the active DTCs, and correct the problem.

Diagnostic request Frame / Diagnostic response Frame

ECU mostly remains in default session.
Some services are found only in default sessions, so the ECU will remain in default
session.
ECU are designed to jump from the non default session to default within 2 - 5ms if
moved to a later session.

RULES: (pg: 37 iso docs)

The ECU on start remains in default session. But it has to explicitly reinitiate the
default session to avail all the services of default or to go to non default session.

All other services available are reseted before jumping to the default session when
moving from the non default session. The tester can remain in the non default
session using the tester presence function and send the signal for 3ms.

—-------------------------xxxxxxxxxxxx—----------------------------

Main Req table, +ve table, -ve table.

Request → red color
+ve response → green
-ve response → blue

Request data frame:

PCI: value → 02(no of bytes) →10 , 01
10→ SID
01 → sub function id
+ve response value:
Response from the server → +ve (50 → 40 + SDI(here it is 10) → 40+10)

Response data frame:

06 →

If the response is received before the defined response time → p2 server time

P2serverMax > P2 Server time →(always)

P2serverMax → def by dev
 If the response is not received within (2ms) the time frame then the ECU
acknowledges the response and responds automatically with msg NRC78→ telling
to wait in the session not to end the session with the P2 servermax (resets the timer
to 5ms).
When P2server max timer gets expired, the ECU resets the timer and sends the
NRC78 and try to process the request within the (8ms) as P2*servermax

If the request is not processed by P2*servermax then again the ECU gives an
NRC78 and resets the timer. It will go on till the request is processed.
No of this reset and NRC 78 thing repetition is decided by the dev. (say only 50
resets are allowed)

If all the NRC numbers are exhausted, the ECU responds with NRC10.
Always P2*servermax > P2servermax timer.

Missed notes: 2.30 - 3pm

9.2 - 9.4
9.5 → read diagnostic and comm mng functional unit
Security access control services:

PCI:

Security access req SID→ 0x27

Eg for request seed:
PCI: 02 Security access req SID Sub function → 01
→ 27

+ve Response key

PCI → 0x02

Response key: 67
Sub funcion → 02
NRC→ negative response time
Off board diagnosis:
0x19 & 0x14 related to each other

Missed notes on DTC

Diagnostic Trouble Code (DTC)

This service allows a client to read the status of server resident Diagnostic Trouble
Code

⎯ Retrieve the number of DTCs matching a client defined DTC status mask
⎯ Retrieve the list of all DTCs matching a client defined DTC status mask
⎯ Retrieve the list of DTCs within a particular functional group matching a client
defined DTC status mask
⎯ Retrieve all DTCs with "permanent DTC" status

● DTCSnapshot (freeze frame) → store data upon detection of a system

malfunction.

AGEING:
When the sensor fails for the threshold times (120 times) and starts to work good for
the same threshold number(120 times), then the log of the failure of the sensor in the
ECU has to be cleared after this process called ageing.

Status mask: → represent each probability of failure case of an ECU ranges from 00
– FF. always the request (0x19) is sent with the status mask.
Most common status task is 2F
EG: 19 01 xx,
xx → mask → 8 bits
We request for the status of the status mask.
Status mask is mentioned in the table below. Status mask consists of all the status of
all 8 parameter.
Operation cycle → the time cycle for which the request happens for. (the test might
occur for every 2ms)

State → 1 → failed
Pending DTC → the DTC is not cleared yet

6/5/22
Messages are sent either
segmented → Multi frame
Un -segmented → single frame

The UDS greatly connected with the CANTP

OSI protocol communication flow

How is the Transfer protocol(TP) layer essential ??

 transport layer facilitates diagnostic communication between external test
equipment and vehicle electronic components.

● In UDS data are transferred asynchronously (say CAN). To transfer the data,
the transfer protocols are used to make the communication sync (send the
data frames in sequence) between the layers (ECU).
● Mostly the extended CAN is used for communication in case of CAN.

Every ECU has phy IDE (11bit)

Use functional IDE instead of the physical IDE if the phy IDE is not known
Functional IDE → the ID (identifier) of each network

PDU = PCI + SDU

PCI→ represent the nature of the ?SDU

CAn TP has the buffer tankfonsecuentive tame si used to represent