Mastère Professionnel Co-

Construit M2 Ingénierie
Automobile et Aéronautique

Automotive
Technologies

Omar Triki Lecture 4 2023-2024

Diagnostic Session Control (0x10): This service is used to establish and control the diagnostic sessions with the
ECU. There are different types of sessions, such as default, programming, extended, and user-defined sessions.
ECU Reset (0x11): This service allows resetting an ECU to its default state, which can be useful during diagnostics
and software updates.
Read Data by Identifier (0x22): It enables the retrieval of data from the ECU based on a specified identifier, such as
sensor values or ECU information.
Read Memory by Address (0x23): This service is used to read data from a specific memory address within an ECU,
typically used for reading stored fault codes.
Security Access (0x27): This service is used to request and grant security access to protected functions in an ECU.
It helps ensure that only authorized users or diagnostic equipment can perform certain actions.
Communication Control (0x28): It allows controlling the communication between the diagnostic tool and the ECU,
useful for tasks like waking up a sleeping ECU.
Tester Present (0x3E): This service is used to inform the ECU that the diagnostic tester is still connected and active.
Control DTC Settings (0x85): This service allows configuring the behavior of Diagnostic Trouble Codes (DTCs), such
as enabling or disabling specific codes or clearing them.
Routine Control (0x31): It is used for controlling and executing routines or tests within the ECU, like emission tests
or component activation.
Write Data by Identifier (0x2E): This service is used to modify values in the ECU, such as setting configuration
parameters or actuating components.
Request Download (0x34) and Transfer Data (0x36): These services are used for software download and firmware
updates in ECUs.
Request Upload (0x35) and Transfer Data (0x36): These services are used for uploading data from the ECU, such
as log files or configuration data.
Diagnostic Session Control (0x10)
Initialization: When a diagnostic tool (such as a scan tool or diagnostic software) establishes communication with
a vehicle's OBD (On-Board Diagnostics) system, it typically starts by initiating a diagnostic session using the
Diagnostic Session Control service (0x10).
Request: The diagnostic tool sends a UDS request message with the service identifier 0x10 to the appropriate ECU
in the vehicle. This request specifies the type of diagnostic session to be established. There are several types of
diagnostic sessions, including default session, programming session, extended diagnostic session, etc. The request
also contains additional parameters to define the session's properties and options.
Response: The ECU responds to the request with a UDS response message. The response typically indicates
whether the requested diagnostic session has been successfully initiated or if there was an error. If successful, it
may provide additional information about the session, such as the session duration or any required security
access.
Session Control: Once the diagnostic session is established, the diagnostic tool can use various UDS services to
perform diagnostic operations on the vehicle's ECUs. The type of operations that can be performed depends on
the diagnostic session's mode and the capabilities of the ECUs involved.
Termination: After the diagnostic operations are complete, the diagnostic session can be terminated. This is
usually done by sending another Diagnostic Session Control request (0x10) with a different session type (e.g.,
ending the current session and returning to the default session). Alternatively, the session may also be terminated
automatically based on predefined conditions.
Error Handling: If any errors occur during the session, the ECU can respond with error codes and messages to
provide diagnostic information to the tool. These error codes help diagnose issues within the vehicle's systems.
ECU Reset (0x11)

Request: The diagnostic tool sends a UDS request to the specific ECU that needs to be reset. This request includes
parameters such as the ECU's identifier and the type of reset operation to be performed (e.g., soft reset or hard
reset).
Processing: The targeted ECU receives the request and processes it. Depending on the type of reset requested, the
ECU may perform different actions:
Soft Reset: This typically involves resetting the ECU's internal variables and counters to their default values. It
does not usually affect the ECU's configuration or programming.
Hard Reset: This is a more comprehensive reset that can involve returning the ECU to its factory default
settings. It may clear configuration data, learned values, and other settings, effectively returning the ECU to
its initial state.
Response: After performing the reset operation, the ECU sends a response back to the diagnostic tool. This
response usually includes status information indicating whether the reset was successful or not.
Verification: The diagnostic tool can verify the status in the response to determine if the ECU reset was successful.
If the reset was successful, the ECU should be in its default state, and any issues or faults that were present may
have been cleared.
Read Data by Identifier (0x22)
The UDS service with the identifier 0x22 is known as the "Read Data by Identifier" service. This service is used to
request specific data values or parameters from the ECUs in a vehicle by specifying a unique identifier (Data
Identifier or DID).
Request:
• The diagnostic tool sends a UDS request message to the target ECU (Electronic Control Unit).
• The request message includes the service identifier 0x22 to indicate that it's a "Read Data by Identifier"
request.
• The request message also includes the Data Identifier (DID) for the specific data parameter that the
diagnostic tool wants to read. The DID is typically a unique number or code that identifies the parameter or
data value the tool is interested in.
Processing:
• The target ECU receives the UDS request and identifies that it's a "Read Data by Identifier" service request.
• The ECU looks up the DID specified in the request to determine which data parameter is being requested.
Response:
• The ECU then constructs a UDS response message.
• The response message typically includes the requested data value associated with the specified DID.
• The response message may also include additional information, such as status information or any relevant
scaling factors.
Read Memory by Address (0x23)

1. Request: The diagnostic tool or tester initiates communication with the target ECU using UDS communication.
It sends a request message for service 0x23, specifying the following parameters:

• Address: The memory address from which data needs to be read.

• Length: The number of bytes to read from the specified address.

2. ECU Processing: The target ECU receives the request and validates it. If the ECU supports the Read Memory by
Address service and the requested address is within its accessible memory range, it proceeds with the
operation.

3. Data Transfer: The ECU retrieves the requested data from the specified memory address and sends it back to
the diagnostic tool in a response message. The response typically includes:

• Data: The actual data read from the memory location.

• Status: A status byte indicating whether the operation was successful or if any errors occurred during the
read operation.
Security Access (0x27)

The Security Access service, represented by 0x27, plays a crucial role in ensuring the security and protection of
sensitive functions within ECUs. Here's how the UDS Security Access service works:

Initialization: Before any diagnostic operations can be performed on an ECU, especially those related to critical or
security-sensitive functions, the diagnostic tool (usually a scanner or tester) must request permission to access
these functions. This is where the Security Access service comes into play.

Seed and Key: When a request for Security Access is made (0x27), the ECU responds with a "Seed" value. This
Seed is a random or semi-random value generated by the ECU. The Seed is typically encrypted or obfuscated in
some way to protect it from unauthorized access.

Request for Key: The diagnostic tool receives the Seed from the ECU and must now calculate a "Key" value based
on a predefined algorithm. This algorithm can be a mathematical operation, encryption, or any other security
mechanism that both the diagnostic tool and the ECU understand.

Key Calculation: The diagnostic tool performs the necessary calculations on the Seed to generate the Key. This
calculation may involve cryptographic processes or other security measures to ensure the Key is valid and secure.
Security Access (0x27)

Key Validation: Once the Key is calculated, the diagnostic tool sends it back to the ECU as a response to the
Security Access request.

Access Granted: The ECU receives the Key and validates it against its own internal calculation. If the Key provided
by the diagnostic tool matches the one calculated by the ECU, access to the secured functions is granted. If there's
a mismatch or the Key is invalid, access is denied.

Secure Access: If access is granted, the diagnostic tool can proceed to perform the necessary diagnostic
operations, which may include reading or writing data, modifying parameters, or executing tests on the ECU.

The Security Access service is designed to prevent unauthorized access to critical ECU functions, which is essential
for protecting vehicle security and safety. It's a security measure commonly used in modern vehicles to ensure that
only authorized technicians or service personnel can access and modify certain parameters or functions within the
vehicle's control units. The specific algorithms and encryption methods used for Seed and Key generation can vary
depending on the manufacturer and the ECU's security requirements.
Communication Control (0x28)
Request Message: When a diagnostic tool wants to control the communication of a specific ECU, it sends a request
message with the service identifier 0x28 and additional data specifying the actions to be taken.
Response Message: The targeted ECU processes the request and responds with a message indicating whether the
requested communication control action was successful or not.
Possible Actions:
• Enable Communication: This action allows an ECU to resume normal communication with other ECUs and
the diagnostic tool. This is typically used after communication has been disabled for some reason, such as
during a diagnostic operation.
• Disable Communication: This action can be used to temporarily disable communication with an ECU. This
is useful for isolating an ECU from the network to perform certain diagnostic tasks without interference
from other ECUs.
• Enable Rx and Disable Tx: This action allows the ECU to receive messages but prevents it from transmitting
messages. This can be useful in specific diagnostic scenarios.
Response: The ECU responds with a message indicating whether the requested action was successful or not. If
successful, communication control is adjusted according to the requested action. If not successful, an error
message is sent to the diagnostic tool, explaining the reason for the failure.
Normal Operation: Once the requested communication control action has been performed, the ECU will operate
according to the specified communication behavior until it receives another communication control request to
change its state.
Tester Present (0x3E)
The service 0x3E, commonly referred to as "Tester Present," is a diagnostic service that serves as a keep-alive
mechanism between the diagnostic tool (often referred to as the tester) and the vehicle's ECUs.
Purpose: The primary purpose of the Tester Present service is to let the vehicle's ECUs know that the diagnostic
tool or tester is still connected and active. This helps prevent the ECUs from entering a sleep mode or taking other
actions that might disrupt the diagnostic process.
Request and Response: Tester Present is a simple service with no parameters or data fields in the request
message. The diagnostic tool sends a request with the service ID 0x3E to the ECU it's communicating with. The
ECU is expected to respond with a positive response (usually a positive response code) to acknowledge that it is
still actively communicating with the tester. The Tester Present service is often used in a periodic manner, with the
diagnostic tool sending requests at regular intervals (e.g., every few seconds). This keeps the communication
channel alive, preventing the ECUs from timing out or disconnecting due to inactivity.
Timeout Handling: If the diagnostic tool does not receive a response from the ECU within a certain timeout
period, it may assume that the connection has been lost or that the ECU is no longer responsive. In such cases, the
diagnostic tool may take appropriate actions, such as displaying an error message or attempting to reconnect.
Implementation Variations: The exact behavior and response codes for the Tester Present service can vary
between different vehicle manufacturers and ECU implementations. The UDS standard defines the service but
allows for some flexibility in its implementation.
Control DTC Settings (0x85)
The Control DTC Settings service typically involves the following parameters:

DTC Status: This parameter is used to specify whether the request is for setting or clearing DTCs. It can have two
values:
• 0x01: Set DTCs (Activate DTCs, i.e., enable the storage and reporting of specific DTCs).
• 0x02: Clear DTCs (Deactivate DTCs, i.e., disable the storage and reporting of specific DTCs).
DTC Setting Type: This parameter specifies the type of DTC configuration to be performed. It can include options
such as:
• Permanent DTCs: DTCs that cannot be cleared by the vehicle operator.
• Pending DTCs: DTCs that are pending confirmation before they become permanent.
• Temporary DTCs: DTCs that are considered non-persistent and may clear on their own.
DTC Group: In some implementations, this parameter allows grouping DTCs into specific categories or subsystems,
enabling selective configuration for different sets of DTCs.
DTC Code: This parameter specifies the specific Diagnostic Trouble Code that you want to configure. DTCs are
typically identified by a numeric code and description, such as P0123 (Throttle/Pedal Position Sensor A Circuit High
Input).
Control Option: This parameter may be used to set additional options related to the DTC, such as enabling or
disabling MIL (Malfunction Indicator Lamp) illumination or configuring freeze frame data.
Routine Control (0x31)
The UDS service 0x31, Routine Control, is used to start or stop routines or diagnostic tests within an ECU. It allows
external systems, such as diagnostic tools or service equipment, to initiate predefined routines or tests within the
vehicle's control units. These routines could include tasks like emissions testing, sensor calibration, or other
diagnostic procedures. Here are the basic parameters used with UDS service 0x31:
• Sub-function (Sub-function code): This parameter specifies the specific action to be performed on the routine
or diagnostic test. Common sub-functions include:
 Start Routine: This sub-function initiates a diagnostic routine or test within the ECU.
 Stop Routine: This sub-function stops an ongoing diagnostic routine or test.
 Request Routine Results: This sub-function is used to request the results of a completed routine.
• Routine Identifier (Routine ID): This parameter specifies which routine or diagnostic test should be started,
stopped, or queried for results. Each routine or test within an ECU is assigned a unique identifier.
• Routine Control Options: Depending on the implementation, this parameter may include additional options or
flags related to the control of the routine, such as the selection of a specific variant of the routine or test.
• Data: Some sub-functions may require additional data parameters to provide necessary information to the ECU,
such as input parameters for the routine.
• Response: The response to a Routine Control request typically includes information about whether the
requested action was successful or not. If the sub-function is "Request Routine Results," the response will also
contain the results of the completed routine or test.
Write Data by Identifier (0x2E)

Service 0x2E is used to write data to specific memory locations within an ECU. This service is often used for tasks
like configuring ECU parameters. Here's a simplified overview of how it is implemented:

Request Frame: The diagnostic tool (e.g., a scan tool or diagnostic software) initiates communication by sending a
UDS request frame to the target ECU. The request frame for service 0x2E typically includes:

• Service Identifier (SID): 0x2E, indicating the Write Data by Identifier service.
• Parameter Record (PR): This contains the Data Identifier (DID) and the Data Record (DR), which holds the data
to be written.
ECU Processing: The target ECU receives the request and extracts the Data Identifier (DID) from the Parameter
Record. The DID is a numeric identifier that specifies which parameter or memory location should be written to.
The ECU looks up the Data Identifier in its internal database to determine the exact memory location where the
data should be written. It then writes the data provided in the Data Record (DR) to that memory location. The data
format and size depend on the specific parameter being configured.

Response Frame: After writing the data, the ECU sends a UDS response frame back to the diagnostic tool. The
response frame typically includes:
Request Download (0x34) and Transfer Data (0x36)

The UDS services you mentioned, Request Download (0x34) and Transfer Data (0x36), are part of the UDS protocol
and are used for updating or transferring data to the electronic control units (ECUs) in the vehicle. These services
are often used for tasks like firmware updates or configuration parameter changes. Here's how they work:
Request Download (0x34):
Purpose: This service is used to request permission from the ECU to download data or firmware.
Parameters: When sending a Request Download request, the diagnostic tool specifies the data format, data
length, and other relevant information about the data to be downloaded. This allows the ECU to prepare for
the data transfer.
Response: The ECU responds with a positive or negative acknowledgment. If the ECU accepts the request, it
sends a positive response along with information about how the data should be transferred (e.g., block size).
Transfer Data (0x36):
Purpose: After receiving permission through Request Download, this service is used to send the actual data
to the ECU in multiple blocks.
Parameters: The Transfer Data service specifies the sequence number, block size, and the actual data to be
sent in each block.
Response: After receiving each block of data, the ECU responds with an acknowledgment, allowing the
diagnostic tool to send the next block. This process continues until all data has been transferred.
Completion: Once all data has been successfully transferred, the ECU can perform tasks like updating its
firmware or applying configuration changes.
Request Upload (0x35) and Transfer Data (0x36)

Request Upload (0x35):

The Request Upload service is used when the diagnostic tool (such as a scan tool or diagnostic software) wants to
request data from an ECU. This service allows the diagnostic tool to specify the type of data it wants to receive
from the ECU. Here's an overview of how it works:
• The diagnostic tool sends a Request Upload request (0x35) to the target ECU.
• The request includes parameters that specify the type of data and the format in which the data should be
returned.
• The ECU receives the request and processes it. If the requested data is available and the ECU supports this
service, it prepares the data for transfer.

Transfer Data (0x36):

The Transfer Data service is used to transfer the requested data from the ECU to the diagnostic tool. It is typically
used after the Request Upload service has been used to request specific data. Here's how it works:
• After receiving a valid Request Upload request and preparing the data, the ECU responds with a Transfer
Data request (0x36).
• The response includes the requested data in a specified format, which can vary depending on the request
parameters and the ECU's capabilities.
• The diagnostic tool receives the data and processes it for further analysis or display to the user.
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
 Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique