UNIFIED

DIAGNOSTIC
SERVICES
[email protected]

TUAN HOANG , L07 OF ES COURSE, 2023

LOOK BACK

2
Agenda
1 What is the UDS?

2 UDS message structure

3 UDS security

4 CAN ISO-TP

5 Related to UDS
DIAGNOSIS IN HEALTHCARE

4
WHAT IS VEHICLE DIAGNOSTICS?

A diagnostic check is a process of checking a vehicle’s systems and components to help identify issues
and rectify them. Modern vehicles are equipped with extensive computer networks that can provide
information on the engine, brakes, and other related systems.

5
WHAT IS THE UDS PROTOCOL?
Unified Diagnostic Services (UDS)
 Unified: Standard combined from KWP200 & other standards.
 Diagnostic: Finding root cause in defects
 Services: Something which makes back to its original state or working without modifying any major level component.

Unified Diagnostic Services (UDS) is a communication protocol used in automotive Electronic Control Units
(ECUs) to enable diagnostics, firmware updates, routine testing and more.

• The UDS protocol (ISO 14229) is standardized across both

manufacturers and standards (such as CAN, KWP 2000,
Ethernet, LIN). Further, UDS is today used in ECUs across all
tier 1 Original Equipment Manufacturers (OEMs).
• In practice, UDS communication is performed in a client-
server relationship - with the client being a tester-tool and
the server being a vehicle ECU. For example, you can connect
a CAN bus interface to the OBD2 connector of a car and send
• UDS requests into the vehicle. Assuming the targeted ECU
supports UDS services, it will respond accordingly.
6
WHAT IS OBD2?
In short, OBD2 is your vehicle's built-in self-diagnostic system.

Link between OBD2 and CAN bus ?

On board diagnostics, OBD2, is a ' higher layer protocol ' (like a language). CAN is a method for
communication (like a phone). In particular, the OBD2 standard specifies the OBD2 connector, incl. a set of
five protocols that it can run on. Further, since 2008, CAN bus ( ISO 15765 ) has been the mandatory protocol
for OBD2 in all cars sold in the US.
In turn, this enables various use cases:
Read/clear diagnostic trouble codes (DTC) for troubleshooting vehicle issues
● Extract parameter data values such as temperatures, state of charge, VIN etc
● Initiate diagnostic sessions to e.g. test safety-critical features
● Modify ECU behavior via resets, firmware flashing and settings modification 7
Agenda
1 What is the UDS?

2 UDS message structure

3 UDS security

4 CAN ISO-TP

5 Related to UDS
UDS MESSAGE STRUCTURE
UDS is a request-based protocol.
an example of an UDS request frame (using CAN bus ):

CAN data frames are the only type of CAN frames that are
used during normal UDS communication. CAN data frames
are made up of many different fields, but the key in our case
(these influenced by UDS protocol)

9
UDS MESSAGE STRUCTURE

CAN ID is a field that informs every receiving CAN Data Field

CAN node about a sender and a content of CAN Data consists of CAN frame payload bytes. The number of bytes
frames. CAN nodes shall filter out and ignore that CAN Data Field contains is determined by frame’s DLC values as
CAN frames that are not relevant for them. In presented in the table. CAN frames that are exchanged during UDS
a normal situation, a CAN node detects a communication must have Data Length Code (DLC) equal to 8 (for
transmission of incoming CAN frames and CLASSICAL CAN and CAN FD) or greater (for CAN FD). The only
once the identifier value (of a CAN frame) is exception is usage of CAN Frame Data Optimization.
decoded, the CAN node shall stop further CAN Frame Data Padding:
listening to the frame if the CAN node is not a If a number of bytes specified in a UDS Packet is shorter than a
recipient of the frame. number of bytes in CAN frame’s data field, then the sender has to
There are two formats of CAN ID: pad any unused bytes in the frame. Note: CAN frame data padding
Standard (11-bit Identifier) is mandatory for CAN frames with DLC>8 and optional for frames
Extended (29-bit identifier) with DLC=8.
10
UDS MESSAGE STRUCTURE

#1 Protocol Control #2 UDS Service ID (SID) UDS Sub Function Byte

Information (PCI) The use cases outlined above relate to The sub function byte is used in some UDS
The PCI field is not per se different UDS services. When you wish to request frames as outlined below. Note,
however, that in some UDS services, like 0x22,
related to the UDS request utilize a specific UDS service, the UDS
the sub function byte is not used. Generally,
itself but is required for request message should contain the UDS when a request is sent to an ECU, the ECU may
diagnostic UDS requests Service Identifier (SID) in the data respond positively or negatively. In case the
made on CAN bus. In short, payload. Note that the identifiers are split response is positive, the tester may want to
the PCI field can be 1-3 bytes between request SIDs (e.g. 0x22) and suppress the response (as it may be irrelevant).
long and contains response SIDs (e.g. 0x62). As in OBD2, the This is done by setting the 1st bit to 1 in the
information related to the response SIDs generally add 0x40 to the sub function byte. Negative responses cannot
transmission of messages request SIDs. be suppressed.
The remaining 7 bits can be used to define up
that do not fit within a single See also the overview of all standardized
to 128 sub function values. For example, when
CAN frame UDS services and SIDs. We will mainly reading DTC information via SID 0x19 (Read
focus on UDS service 0x22 in this article, Diagnostic Information), the sub function can
which is used to read data (e.g. speed, be used to control the report type.
SoC, temperature, VIN) from an ECU. 11
UDS MESSAGE STRUCTURE

12
UDS MESSAGE STRUCTURE

The standardized UDS services shown above are in practice a subset of a larger set of diagnostic services - see below
overview. Note here that the SIDs 0x00 to 0x0F are reserved for legislated OBD services (more on this later).

13
UDS MESSAGE STRUCTURE

14
UDS MESSAGE STRUCTURE
Example: Service 0x19 sub functions
If we look specifically at service
0x19, we can see an example of the
various sub functions below:

15
UDS MESSAGE STRUCTURE
• Service 0x22 (Read Data by Identifier) - Data Identifiers
• Another example is service 0x22 (Read Data by
Identifier). This service uses a Data Identifier (DID),
which is a 2-byte value between 0 and 65535 (0xFFFF).
The DID serves as a parameter identifier for both
requests/responses (similar to how the parameter
identifier, or PID, is used in OBD2).
• For example, a request for reading data via a single
DID in UDS over CAN would include the PCI field, the
UDS service 0x22 and the 2-byte DID. Alternatively,
one can request data for additional DIDs by adding
them after the initial DID in the request. We will look
further into this in the section on how to record and
decode UDS communication.
• Data Identifiers can be proprietary and only known by
OEMs, though some DIDs are standardized. This is for
example the case for the WWH-OBD DIDs (more on
this later) and the Vehicle Identification Number (VIN)
is 0xF190. See the separate table for a list of
standardized DIDs across UDS.
16
Agenda
1 What is the UDS?

2 UDS message structure

3 UDS security

4 CAN ISO-TP

5 Related to UDS
UDS SECURITY VIA SESSION-CONTROL (AUTHENTICATION)
• As evident, UDS enables extensive control over the vehicle ECUs. For security reasons, critical UDS
services are therefore restricted through an authentication process. Basically, an ECU will send a
'seed' to a tester, who in turn must produce a 'key' to gain access to security-critical services. To
retain this access, the tester needs to send a 'tester present' message periodically.

• In practice, this authentication process enables vehicle manufactures to restrict UDS access for
aftermarket users and ensure that only designated tools will be able to utilize the security-critical
UDS services.

• Note that the switching between authentication levels is done through diagnostic session control,
which is one of the UDS services available. Vehicle manufactures can decide which sessions are
supported, though they must always support the 'default session' (i.e. which does not involve any
authentication). With that said, they decide what services are supported within the default session as
well. If a tester tool switches to a non-default session, it must send a 'tester present' message
periodically to avoid being returned to the default session.

18
POSITIVE VS. NEGATIVE UDS RESPONSES
When an ECU responds positively to an UDS request, the response frame is structured with similar elements
as the request frame. For example, a 'positive' response to a service 0x22 request will contain the response
SID 0x62 (0x22 + 0x40) and the 2-byte DID, followed by the actual data payload for the requested DID.
Generally, the structure of a positive UDS response message depends on the service. However, in some cases
an ECU may provide a negative response to an UDS request - for example if the service is not supported. A
negative response is structured as in below CAN frame example:

Details + Negative Response Code table

Below we briefly detail the negative response frame with focus on the NRC:
● The 1st byte is the PCI field
● The 2nd byte is the Negative Response Code SID, 0x7F
● The 3rd byte is the SID of the rejected request
● The 4th byte is the Negative Response Code (NRC)
In the negative UDS response, the NRC provides information regarding the cause of the rejection as per the table
below. 19
NEGATIVE UDS RESPONSES

20
UDS VS CAN BUS

The Controller Area Network serves as a basis for communication. Specifically, CAN is described by a data-link
layer and physical layer in the OSI model (as per ISO 11898). In contrast to CAN, UDS (ISO 14229) is a 'higher layer
protocol' and utilizes both the session layer (5th) and application layer (7th) in the OSI model.
21
UDS VS CAN BUS
Quick overview of the UDS OSI model layers
In the following we provide a quick breakdown of each layer of the OSI model:
● Application: This is described by ISO 14229-1 (across the various serial data link
layers). Further, separate ISO standards describe the UDS application layer for the
various lower layer protocols - e.g. ISO 14229-3 for CAN bus (aka UDSonCAN)
● Presentation: This is vehicle manufacturer specific
● Session: This is described in ISO 14229-2
● Transport + Network: For CAN, ISO 15765-2 is used (aka ISO-TP)
● Data Link: In the case of CAN, this is described by ISO 11898-1
● Physical: In the case of CAN, this is described by ISO 11898-2

As illustrated, multiple standards other than CAN may be used as the basis for UDS
communication - including FlexRay, Ethernet, LIN bus and K-line. In this tutorial we focus
on CAN, which is also the most common lower layer protocol.
22
UDSONCAN VS DOCAN
When talking about UDS based on CAN bus, you'll often see two terms used: UDSonCAN (UDS on CAN bus)
and DoCAN (Diagnostics on CAN bus). Some UDS tutorials use these terms interchangeably, which may
cause confusion.

In ISO 14229-1 the terms are used as in our OSI model illustration. In other words, UDSonCAN is used to
refer to ISO 14229-3, while DoCAN is used to refer to ISO 15765-2 aka ISO-TP.

However, part of the confusion may arise because ISO 14229-3 also provides an OSI model where DoCAN is
both used in relation to ISO 15765-2 and as an overlay across OSI model layers 2 to 7. In ISO 14229-2,
DoCAN is referred to as the communication protocol on which UDS (ISO 14229-1) is implemented. This is in
sync with the illustration from ISO 14229-3. In this context, DoCAN can be viewed as a more overarching
term for the implementation of UDS on CAN, whereas UDSonCAN seems consistently to refer to ISO 14229-
3 only.

ISO 15765-3 vs. ISO 14229-3

UDS on CAN bus (UDSonCAN) is sometimes referred to through ISO 15765-3. However, this standard is
now obsolete and has been replaced by ISO 14229-3.
23
Agenda
1 What is the UDS?

2 UDS message structure

3 UDS security

4 CAN ISO-TP

5 Related to UDS
CAN ISO-TP - TRANSPORT PROTOCOL
CAN ISO-TP - Transport Protocol (ISO 15765-2)
When implementing diagnostics on CAN, one challenge is the size of the CAN frame payload: For Classical CAN frames,
this is limited to 8 bytes and for CAN FD the payload is limited to 64 bytes. Vehicle diagnostics often involve
communication of far larger payloads.
ISO 15765-2 was established to solve the challenge of large payloads for CAN based vehicle diagnostics. The standard
specifies a transport protocol and network layer services for use in CAN based vehicle networks. The most common use
cases include UDS (ISO 14229-1), OBD (SAE J1979, ISO 15031-5) and world-wide harmonized OBD aka WWH-OBD (ISO
27145).
The ISO-TP standard outlines how to communicate CAN data payloads up to 4095 bytes through segmentation, flow
control and reassembly. ISO-TP defines specific CAN frames for enabling this communication as shown below

25
ISO-TP: SINGLE-FRAME COMMUNICATION
In vehicle diagnostics, communication is initiated by a tester tool sending a request. This request frame is
a Single Frame (SF). In the simplest case, a tester tool sends a Single Frame to request data from an ECU. If
the response can be contained in a 7-byte payload, the ECU provides a Single Frame response.

26
ISO-TP: MULTI-FRAME COMMUNICATION

27
EXAMPLE 1: RECORD SINGLE FRAME UDS DATA (SPEED VIA WWH-OBD)

First, the CANedge2 sends a Single Frame (SF) request:

● The initial 4 bits of the PCI field equal the frame type (0x0 for SF)
● The next 4 bits of the PCI field equal the the length of the request (3 bytes)
● The 2nd byte contains the Service Identifier (SID), in this case 0x22
● The 3rd and 4th bytes contain the DID for Vehicle Speed in WWH-OBD (0xF40D)
● The remaining bytes are padded

In response to this request, the truck responds with a Single Frame (SF) response:
● The 1st byte again reflects the PCI field (now with a length of 4 bytes)
● The 2nd byte is the response SID for Read Data by Identifier (0x62, i.e. 0x22 + 0x40)
● The 3rd and 4th bytes again contain the DID 0xF40D
● The 5th byte contains the value of Vehicle Speed, 0x32
Here we can use the same decoding rules as for ISO/SAE OBD2, meaning that the physical value of
Vehicle Speed is simply the decimal form of 0x32 - i.e. 50 km/h. See also our OBD2 PID conversion tool.
28
EXAMPLE 2: RECORD & DECODE MULTI FRAME UDS DATA (SOC)
We will use the CANedge2 and the UDS service SID 0x22 (Read Data By Identifier) to request the current value of State
of Charge (SoC%) from a Hyundai Kona electric vehicle.
First, the CANedge is configured to send two CAN frames:
1. A Single Frame (SF) request (period: 5000 ms, delay: 0 ms)
2. A Flow Control (FC) frame (period: 5000 ms, delay: 100 ms)

29
EXAMPLE 2: RECORD & DECODE MULTI FRAME UDS DATA (SOC)
Communication flow details
In the following we explore this communication between the CANedge and ECU in detail. First of all, the initial Single
Frame (SF) request is constructed via the same logic as in our previous example - containing the PCI field, the SID 0x22
and the DID. In this case, we use the DID 0x0101. In response to the initial SF request, the targeted ECU sends a First
Frame (FF) response:
● The initial 4 bits equal the frame type (0x1 for FF)
● The next 12 bits equal the data payload size, in this case 62 bytes (0x03E)
● The 3rd byte is the response SID for Read Data by Identifier (0x62, i.e. 0x22 + 0x40)
● The 4th and 5th bytes contain the Data Identifier (DID) 0x0101
● The remaining bytes contain the initial part of the data payload for the DID 0x0101

Following the FF, the tester tool now sends the Flow Control (FC) frame:
● The initial 4 bits equal the frame type (0x3 for FC)
● The next 4 bits specifies that the ECU should "Continue to Send" (0x0)
● The 2nd byte sets remaining frames to be sent without flow control or delay
● The 3rd byte sets the minimum consecutive frame separation time (ST) to 0

Once the ECU receives the FC, it sends the remaining Consecutive Frames (CF):
● The initial 4 bits equal the frame type (0x2 for CF)
● The next 4 bits equal the index counter, incremented from 1 up to 8 in this case
● The remaining 7 bytes of each CF contain the rest of the payload for the DID 30
EXAMPLE 3: RECORD THE VEHICLE IDENTIFICATION NUMBER
The Vehicle Identification Number (aka VIN, chassis number, frame number) is a unique identifier code used for road
vehicles. The number has been standardized and legally required since the 1980s - for details see the VIN page on
Wikipedia

A VIN consists of 17 ASCII characters and can be extracted on-request from a vehicle. This is useful in e.g.
data logging or telematics use cases where a unique identifier is required for association with e.g. CAN bus
log files.

CAN data bytes can be converted from HEX to ASCII via tables, online HEX to ASCII converters , Python
packages etc. For example, the byte 0x47 corresponds to the letter "G". Since a VIN is 17 bytes (17 ASCII
characters) long, it does not fit into a single CAN frame, but has to be extracted via a multi frame diagnostic
request/response as in Example 2. Further, the VIN is extracted differently depending on the protocol used.
31
EXAMPLE 3: RECORD THE VEHICLE IDENTIFICATION NUMBER
How to record the VIN via UDS (ISO 14229-2)
To read the Vehicle Identification Number via UDS, you can use the UDS SID 0x22 and the DID 0xF190:

As evident, the request/response communication flow looks similar to the OBD2 case above. The main
changes relate to the use of the UDS service 0x22 instead of the OBD2 service 0x09 - and the use of the 2-
byte UDS DID 0xF190 instead of the 1 byte OBD2 PID 0x02. Further, the UDS response frame does not
include the Number of Data Items (NODI) field after the DID, in contrast to what we saw in the OBD2 case.

32
HOW TO REASSEMBLE AND DECODE MULTI-FRAME UDS DATA?

33
Agenda
1 What is the UDS?

2 UDS message structure

3 UDS security

4 CAN ISO-TP

5 Related to UDS
WHAT DATA CAN I LOG VIA UDS?
• A very common use case for recording UDS data via 'standalone' data loggers will be to acquire
diagnostic trouble code values, e.g. for use in diagnosing issues.

• In addition to the trouble codes, UDS lets you request the 'current value" of various sensors related to
each ECU. This allows e.g. vehicle fleet managers, researchers etc. to collect data of interest such as
speed, RPM, state of charge, temperatures etc. from the car (assuming they know how to
request/decode the data, as explained below).

• Beyond the above, UDS can of course also be used for more low-level control of ECUs, e.g. resets and
flashing of firmware, though such use cases are more commonly performed using a CAN bus interface -
rather than a 'standalone’ device.

35
IS UDS DATA PROPRIETARY - OR ARE THERE PUBLIC PARAMETERS?
• Importantly, UDS is a manufacturer specific diagnostic protocol. In other words, while UDS provides a
standardized structure for diagnostic communication, the actual 'content" of the communication
remains proprietary and is in most cases only known to the manufacturer of a specific vehicle/ECU.

• For example, UDS standardizes how to request parameter data from an ECU via the 'Read Data By
Identifier" service (0x22). But it does not specify a list of standardized identifiers and interpretation
rules. In this way, UDS differs from OBD2, where a public list of OBD2 PIDs enable almost anyone to
interpret OBD2 data from their car.

• With that said, vehicles that support WWH-OBD or OBDonUDS may support some of the usual OBD2
PIDs like speed, RPM etc via the usual PID values - but with a prefix of 0xF4 as shown in Example 1
below.

• Generally, only the manufacturer (OEM) will know how to request proprietary parameters via UDS - and
how to interpret the result. Of course, one exception to this rule is cases where companies or
individuals successfully reverse engineer this information. Engaging in such reverse engineering is a very
difficult task, but you can sometimes find public information and DBC files where others have done this
exercise. Our intro to DBC files contain a list of public DBC/decoding databases.
36
WHO BENEFITS FROM LOGGING UDS DATA?
• Because of the proprietary nature of UDS communication, it is typically most relevant to automotive
engineers working at OEMs. Tools like the CANedge CAN bus data logger allow these users to record
raw CAN traffic from a vehicle – while at the same time requesting diagnostic trouble codes and
specific parameter values via UDS.

• Further, some after market users like vehicle fleet managers and even private persons can benefit from
UDS assuming they are able to identify the reverse engineered information required to request and
decode the UDS parameters of interest.

• Logging UDS data will also become increasingly relevant assuming WWH-OBD gets rolled out as
expected. Already today, WWH-OBD is used in EU heavy duty vehicles produced after 2014, meaning
UDS communication will be relevant for use cases related to on-board diagnostics in these vehicles.

37
CENTRAL GATEWAY (CGW): WHY LOG SENSOR DATA VIA UDS VS. CAN?
• If you're looking to request UDS-based diagnostic trouble codes (DTC), you'll of course have to use UDS communication for this
purpose. However, if your aim is to record current sensor values it is less clear.
• Typically, data parameters of interest for e.g. vehicle telematics (speed, state of charge etc) will already be communicated between
ECUs on the CAN bus in the form of raw CAN frames - without the need for a diagnostic tool requesting this information. That is
because ECUs rely on communicating this information as part of their operation (as explained in our intro to CAN bus ).
• If you have direct access to the CAN bus, it will thus appear easier to simply log this raw CAN traffic and process it. If you are the
vehicle manufacturer; you will know how to interpret this raw CAN data either way - and it'll be simpler to perform your device
configuration and post processing in most cases. If you're in the aftermarket, it'll also be simpler to reverse engineer the raw CAN
frames as you can focus on single frames - and avoid the request/response layer of complexity.
• However, one key reason why UDS is frequently used for extracting sensor values despite the above is due to 'gateways'. Specifically,
an increasing share of modern cars have started to block the access to the raw CAN bus data via the OBD2 connector. This is
particularly often the case for German vehicles, as well as electric vehicles. To record the existing CAN traffic in such a car, you would
need to e.g. use a CANCrocodile adapter and 'snap' it onto the CAN low/high wiring harness. This in turn will require exposing the
wiring harness by removing a panel, which is often prohibitive for many use cases. In contrast, the OBD2 connector gateways
typically still allow for UDS communication - incl. sensor value communication.
• A secondary - and more subtle - reason is that most reverse engineering work is done by 'OBD2 dongle manufacturers’. These
develop tools that let you extract data across many different cars through the OBD2 connector. Increasingly, the only way for these
dongles to get useful information through the OBD2 connector is through UDS communication, which drives a proportionally higher
availability of information/databases related to UDS parameters vs. raw CAN parameters.

38
DOES MY VEHICLE SUPPORT UDS?
• Since most ECUs today support UDS communication, the answer is in "yes, most likely".
• If you're the vehicle manufacturer, you will in most cases have the information required to construct
UDS requests for whatever data you need - and you'll also know how to decode it.
• For the specific case of recording WWH-OBD data in EU trucks, standardized DID information can be
recorded by both OEMs and after-market users - similar to how you can record public OBD2 PIDs from
cars/trucks.
• Beyond the above, if you are in the after market and wish to record proprietary UDS information from a
car/truck, it will be difficult. In this case, you would either have to contact the OEM (e.g. as a system
integrator/partner) or identify the request/decoding information through reverse engineering. The
latter is in practice impossible for most people.
• In select cases you may be able to utilize public information shared on e.g. github to help in
constructing UDS requests - and decoding the responses. Just keep in mind that public resources are
based on reverse engineering efforts – and may risk being incorrect or outdated. You should therefore
take all information with a significant grain of salt.

39
WHY IS UDS INCREASINGLY IMPORTANT?
• If your use case involves recording data from cars produced between 2008 and 2018, you will most
often be interested in data that can be collected via OBD2 data logging. This is because most ICE cars
after 2008 support a large share of the public OBD2 parameter identifiers like speed, RPM, throttle
position, fuel level etc.

• However, the availability of OBD2 data is expected to decrease over time for multiple reasons.

• First of all, as we explained in the previous section, WWH-OBD (based on UDS) or OBDonUDS are
expected to gradually replace OBD2 as the de facto standard for vehicle diagnostics.

• Second, with the rise of electric vehicles, legislated OBD2 is not necessarily supported at all. And even
if an EV supports some OBD2 PIDs, you'll note from our OBD2 PID list that some of the most relevant
EV parameters like State of Charge (SoC) and State of Health (SoH) are not available via OBD2. In
contrast, UDS remains supported in most EVs and will provide access to a far broader range of data -
although without the after-market convenience of a public list of UDS parameters (at least yet). It is
expected that EV sales will overtake ICE car sales between 2030 and 2040 - and thus UDS
communication will become increasingly relevant.

40
REGARDING PROPRIETARY UDS DATA
• Part of the information used here is proprietary. In particular, it is generally not known what Data
Identifier (DID) to use in order to request e.g. State of Charge from a given electric vehicle, unless
you're the vehicle manufacturer (OEM). Further, as explained in the next section, it is not known how
to decode the response payload.

• However, various online resources exist e.g. on github, where enthusiasts create open source
databases for specific parameters and certain cars (based on reverse engineering). The information we
use for this specific communication is taken from one such database.

41
REGARDING THE CAN IDS USED
• In this case we use the CAN ID 0x7E4 to request data from a specific ECU, which in turn responds with
CAN ID 0x7EC. This is known as a physically addressed request.

• In contrast, functionally addressed request would use the CAN ID 0x7DF (or 0x18DB33F1 in heavy duty
vehicles). Generally, request/response CAN IDs are paired (as per the table below) and you can identify
the physical request ID corresponding to a specific physical response ID by subtracting the value 8 from
the response ID. In other words, if an ECU responds via CAN ID 0x7EC, the physical request ID targeting
that ECU would be 0x7E4 (as in our EV example).

• Since you may not know what address to target initially, you can in some cases start by sending out a
functional request using the CAN ID 0x7DF, in which case the relevant ECU should provide a positive
First Frame response if the initial request payload is structured correctly. In some vehicles, you may be
able to also send the subsequent Flow Control frame using the same CAN ID, 0x7DF, in order to trigger
the ECU to send the remaining Consecutive Frames.

• However, some implementations may require that you instead utilize the physical addressing request
ID for the Flow Control frame.
42
REGARDING THE CAN IDS USED
Implementing a request structure with dynamically updating CAN IDs may be difficult. If you're the
manufacturer, you will of course know the relevant CAN IDs to use for sending physically addressed
service requests. If not, you may perform an analysis using e.g. a CAN bus interface to identify what
response CAN IDs appear when sending functionally addressed service requests - and using this
information to construct your configuration.

On a separate note, ISO 15765-4 states

that enhanced diagnostics
requests/responses may utilize the
legislated OBD2 CAN ID range as long as it
does not interfere - which is what we are
seeing in this specific Hyundai Kona
example where the IDs 0x7EC/0x7E4 are
used for proprietary data. See also the
table from ISO 15765-4 for an overview of
the legislated OBD CAN identifiers for use
in functional and physical OBD PID
requests.
43
REGARDING TIMING PARAMETERS
• In the above example, we generally focus on the sequence of CAN frames. The sequence is important:
For example, if your tester tool sends the Flow Control frame before receiving the First Frame, the Flow
Control frame will either be ignored (thus not triggering the Consecutive Frames) or cause an error.

• However, in addition to this, certain timing thresholds will also need to be satisfied. For example, if your
tester tool receives the First Frame from an ECU of a multi frame response, the ECU will 'time out' if the
Flow Control frame is not sent within a set time period.

• As a rule of thumb, you should configure your tester (e.g. the CANedge) so that the Flow Control frame
is always sent after the First Frame response is received from the ECU (typically this happens within 10-
50 ms from sending the initial request) - but in a way so that it is sent within a set time after receiving
the First Frame (e.g. within 0-50 ms). For details on this, feel free to contact us.

44
THANK YOU
FOR YOUR
INTEREST!
UNIFIED DIAGNOSTIC SERVICES
REFERENCE
https://www.csselectronics.com/pages/can-bus-simple-intro-tutorial
https://uds.readthedocs.io/en/latest/pages/knowledge_base/packet.html

46