Introduction to UDS

Article directory

Introduction to UDS

Definition of UDS

The UDS protocol is ISO-14229, which is Unified Diagnostic Services, a unified diagnostic service, and a standardized standard for diagnostic services. The biggest difference from OBD is that UDS is oriented to all ECUs (electronic control units) of the vehicle, while OBD is oriented to the emission system ECU. The main purpose of UDS diagnosis is to quickly and accurately determine the failure of the vehicle or a certain controller and the cause of the failure, so as to provide a reliable basis for maintenance.

Generic protocol for on-board diagnostics, containing different subclass files. Different subclass files apply to different bus communication media in the vehicle:
insert image description here

From the lowest-end physical layer to the upper-most application layer, there are different bus protocols (the dominant vehicle bus CAN, and the introduction of vehicle Ethernet into the vehicle network is the most popular due to the rise of ADAS). From the screenshot above, we can see the UDS protocol A reservation is also made for the new vehicle bus, which fully guarantees the flexibility of the protocol.

Commonly Used Diagnostic Services

UDS diagnosis includes 6 categories and 26 kinds of services, each service has its own independent ID, namely SID (Service Identifier).

insert image description here

UDS diagnostic services can be divided into 6 categories:

diagnostic and communication management functional unit;
Data transmission functional unit;
Stored data transfer functional unit;
Input and output control functional unit;
Routine functional unit;
Upload and download functional units.

In addition to the services in the diagnosis and communication management unit (such as 0x10 session control service, 0x3E session maintenance service), the most commonly used diagnostic services are basically the services in the data transmission function unit (such as 0x22 read DID, 0x2E write DID) and store data Services in the transmission unit (0x19 read DTC, 0x14 clear DTC). The following is a brief introduction to these commonly used diagnostic services.

Diagnostic and Communication Management Functional Unit (Diagnostic and Communication Management)

$10 - session control service (DiagnosticSessionControl) and 0x3E - session persistence service

This service requests the ECU to transition from an active session to another session. Contains three sub-functions: 01 - Default, 02 - Programming, 03 - Extended.

This service is used to control the ECU to switch between different session modes. The default ECU is in the DefaultSession with sub-service number 01. Many services need to be switched to 03 ExtendedSession to execute. When software flashing is required, you need to switch to 02 Programming Session. The switching methods of these three modes are as follows:

insert image description here

When the ECU is in a non-DefaultSession, if there is no diagnostic operation for a period of time, it will return to the DefaultSession. At this time, if you want to keep in the non-DefaultSession, you can maintain the service through the 0x3E session, and the ECU will remain in the current Session.

insert image description here

1. If the ECU is currently in the default session mode, the Client sends 10 01, and the ECU will reset all activated/started/changed settings/controls during the active session;

2. Different conversation modes can be switched arbitrarily;

3. For its own safety, the ECU is not allowed to stay in the non-default session mode for a long time. Within a certain period of time (S3), if the ECU does not receive any diagnostic request, it will force the ECU to jump from the non-default session mode to the default session mode;

4. During the S3 time, if there is no need to send a diagnostic request, but you still want to require the ECU to be in a non-default session mode, you can periodically send Service3E (TesterPresent) to keep the ECU in the current non-default session mode.

$11 - Electronic Control Unit Reset (ECUReset)

This service requests the ECU to perform a reset. Examples of ECUReset request parameters include: hardReset, keyOffOnReset, softReset.

This service mainly performs ECU reset based on the reset type in the request message. Before the ECU resets, the ECU needs to reply with an affirmative response message to reset successfully. After the ECU resets successfully, the ECU should activate the default session.
Commonly used reset types, that is, sub-functions:
11 01 Hard reset, that is, the simulated state is a reset where the power is disconnected and then reconnected.
11 02 Keyoffon reset, which simulates the reset of the type where the driver turns off the ignition switch first and then turns it on again.
11 03 Soft reset, which simulates the reset requested by the software, such as the Reset triggered when unexpected execution occurs inside the software.

$27 - SecurityAccess

This service is used to achieve a higher level of security in active diagnostic sessions. A SecurityAccess request may be required to unlock and access protected functions and data (e.g. read ECU ID information via DID). Can also be used to successfully switch from one session to another by unlocking it.

In order to improve security, some services may require security verification, that is, unlocking. For example, for the reading or writing of some DIDs, it needs to be unlocked before performing the operation. At this time, the 0x27 service needs to be executed. The 0x27 service is composed of a pair of sub-services. The diagnostic instrument requests a seed from the ECU and the diagnostic instrument sends a key to the ECU. Seed and Key generally have an algorithm, and each Seed corresponds to a unique Key, which is usually injected on the production line. After the diagnostic instrument requests the Seed from the ECU, the ECU will return a Seed to the diagnostic instrument, and the diagnostic instrument needs to send the corresponding After the ECU verifies that the Key is correct, it is unlocked, and the diagnostic instrument can perform subsequent operations.

A typical example of using this service is as follows:

The client first sends a diagnostic request requesting the seed;
After receiving the request, the server calculates a random seed and sends it to the client through a diagnostic response;
After the client receives the seed, it uses the defined algorithm to calculate the key, and then sends it to the server through a diagnosis request;
After the server receives the key, it compares it with the key calculated by itself. If they are consistent, the verification is passed. If they are not consistent, the verification fails.

insert image description here

$28 - CommunicationControl

This service requests the ECU to control its communication behavior. A typical example includes asking the ECU in the CAN bus to turn off on-board communication to improve the efficiency of diagnostic communication.

According to the ISO14119-1 standard, the diagnostic service 28 service is mainly used for sending and receiving messages in the network, such as controlling the
sending and receiving of application messages, or controlling the sending and receiving of network management messages.
28 Service sub-functions:
00: enableRxAndTx (enable sending and receiving)
01: enableRxAndDisableTx (enable receiving and prohibit sending)
02: disableRxAndEnableTx (disable receiving and enable sending)
03: disableRxAndTx (disable sending and receiving)

Control type (communicationType):

The third byte is the control type, 01 is all application messages, 02 is all network management messages, and 03 is included.

$3E - Standby handshake (TesterPresent)

TesterPresent requests are usually sent periodically and include a function address. It indicates that the tester is still connected (present) and requests the ECU to keep the current diagnostic state (e.g. a session other than the default session is active, the RoE mechanism is still active). Positive response suppression for this service reduces bus load.

$83 - Access TimingParameter (AccessTimingParameter)

This request is used to read and/or modify communication timing parameters.

$84 - SecuredDataTransmission

This request is used to transmit diagnostic data protected by encryption methods. For this, a "Security Sublayer" between the application layer and the applications of the tester and ECU must be implemented. Data is processed according to ISO 15764 (Security for Extended Data Links).

$85 - Diagnostic Trouble Code Setting Control (ControlDTCSetting)

This service requests the ECU to stop/restore the setting of the DTC. Combining this service with in-vehicle communication switching (service $28 communication control) increases the speed for Flash programming.

This service is used to close the DTC record in the process of diagnostic flashing, because in the process of flashing, it is often for a certain ECU node to flash, and other counterpart ECU nodes are always in normal working state, so at this time it should be The sending function is addressed to each ECU node so that it stops recording DTC, and then restarts the DTC recording function of the counterpart after the flashing is completed.
Commonly used sub-function
85 01: continue to update the status bit of the status code.
85 02: Stop updating status code status bits.

$86 - Event Response (ResponseOnEvent)

The Response on Event (RoE) service requests the ECU to automatically transmit a response to a specified event.

$87 - Link Control (LinkControl)

This service request controls the communication data rate. For CAN, it affects the data link layer specified in ISO 11898, which affects the data rate used for onboard communication as well as diagnostic communication. The request to convert the data rate is divided into: verify that the ECU on the network allows the specific data rate, request the conversion if the verification result is positive, and perform the conversion.

Data Transmission Functional Unit (Data Transmission)

$22 - Read data by ID (ReadDataByldentifier)

This service requests to read the data record value identified by the DID parameter. DID is used to identify a specific local data record. Data identifier 0xF224 can contain data such as battery voltage, manifold absolute pressure, mass air flow, vehicle barometric pressure, and calculated load values.

DID is the data ID, through the 0x22 service, the data can be read out according to the two-byte ID. According to the DID given in the request, a 0x22 service can read the value of one or more DIDs. The 0x2E service generally appears in pairs with the 0x22 service, and is used to write data through the data ID. Of course, some DIDs are read-only, so the corresponding write service must be blocked when configuring the diagnostic database. There are other types of read and write services, such as 0x23 to read memory information according to the address, and 0x3D to write memory information according to the address.

$23 - Read memory by address (ReadMemoryByAddress)

This service requests to read the current value of the specified memory range. The request parameters are memory address and memory size. The number of bytes used for request parameters is specified in addressAndLengthFormatldentifier.

$24 - Read scaling data by ID (ReadScalingDataByidentifier)

This service requests the ECU to transmit scaled information values to the tester. The tester transforms the data using the scaled information values. The implementation of this service increases the utility of the ECU software. Alternatively, the tester may store scaling information in a database.

$2A - Read data by period ID (ReadDataUyPeriodicidentifier)

This service request periodically sends data record values. The transmission rate of the requested data is set by the transmission mode parameter, eg "medium rate send", eg 300 ms.

$2C - Dynamically Define DataIdentifier (DynamicallyDefineDataIdentifier)

This service allows testers to dynamically define new data identifiers in the ECU, which contain references to statically defined identifiers and/or memory addresses. Testers can then read this dynamically defined data record via service request 2A (readDataByPeriodicIdentifier). An advantage of dynamically defined identifiers is that a service can request the transfer of many data records.

$2E - Write data by ID (WriteDataByldentifier)

With this service, a data record specified by an identifier (DID) can be written to the ECU memory.

$3D - Write memory by address (WriteMemoryByAddress)

This service allows data records to be written directly to the ECU's memory. The request parameters are memory address and memory size and data record. The number of bytes used for the parameters memory address and memory size is specified in addressAndLengthFormatidentifier.

Stored Data Transmission Functional Unit (Stored Data Transmission)

$14 - Clear Diagnostic Information (ClearDiagnosticInformation)

Clear (reset) the DTC format, which can change the state of the DTC. This service allows clearing the contents of the error memory in one or more ECUs. Therefore, a service can be requested using a physical address or a functional address. 3 FF means clear all DTCs. For example:
Request: 14 + FF + FF + FF;
Response: 54.

$19 - Read DTC information (ReadDTCInformation)

Diagnostic Trouble Codes (DTCs) are used to code and identify detected emissions-related and non-emissions-related malfunctions. DTC is usually three bytes, OBD II takes up two bytes. This service requests the status of DTC information from one or more ECUs. Therefore, the service can be queried by physical address or functional address. Testers can request stored data records associated with DTCs, also known as "DTC snapshots". A DTC snapshot contains the specific data values at the time the fault occurred.

The 19 service is the most important thing in UDS. It can be said that without the 19 service, the meaning of the diagnostic service will be lost. The function and usage of this service will be introduced in detail below.

The fault code includes four categories, namely PCBU, P is the powertrain power system, C is the chassis chassis, B is the body body, and U is the network communication system. A DTC message occupies 4 bytes. The last byte is the status of the DTC.

19 01 Read the number of DTCs
Use the status mask to find the number of faults that match it. Through this service diagnostic instrument, you can request the number of DTCs in the ECU that match the DTC status and the DTC status mask. If the actual status bit of a certain fault code is 1, and the corresponding bit in the DTC status mask is also 1, then it is considered that the status of the DTC matches the DTC status mask (that is, if the DTC status mask byte The result of the logical "bit AND" operation with the DTC actual status byte is a non-zero value, then the two match); at this time, the number of faults will be +1. If the diagnostic instrument defines a status mask that contains bits that the ECU does not support, then the ECU only uses the bits that it supports to process the fault information.

19 02 Read DTC list
Search for matching faults in the form of the defined status mask: return the matching DTC identifier (3 bytes) and DTC status (1 byte) information. The 01 sub-service in the previous section only counts the number of DTCs that match the status mask, and the 02 sub-service will return the matching DTC information.

19 03 Read DTC snapshot information

19 04 Read the specified DTC snapshot information
In order to find the cause of the fault conveniently, the car factory will generally define some information in the diagnostic questionnaire as snapshot information, such as the fault occurrence time, voltage, mileage, vehicle speed, etc. When the corresponding fault occurs, the ECU needs to record the snapshot information when the fault occurs; and the 04 service is used to request the snapshot information of the specified fault code (DTC), and analyze the cause of the fault by searching for these data at the time of the fault occurrence.

19 06 Read extended data information
In addition to the snapshot information of the previous 04 service; generally, an extended information is defined to record some other information of the fault, such as the number of faults, aging times, and aging times. The 06 service that will be introduced next is the extended information used to request the specified fault code (DTC).

19 0A Read all DTC information
Request all supported DTC information (3-byte DTC identifier + 1-byte DTC status bit), the response message is consistent with the 02 service; but it should be distinguished that the service returns all DTC information; and the 02 service returns DTC information whose sum with the status mask at the time of request is not 0.

Input and output control functional unit (Input & Output Control)

$2F - Control input and output by identifier (InputOutputControlByIdentifier)

This service is mainly used to replace the value of the input signal and/or control the output of the ECU. Typically, this service bypasses the ECU's application software and directly triggers the output circuit, which then directly reads the sensor connected to the input circuit.

Routine function unit (Remote Activation of Routine)

$31 - RoutineControl

This service is used to maintain and stop ECU internal routines. The results of the routine can be read for analysis. The routine is identified by the two-byte routine identifier.

Clients use 31 services to execute a defined sequence of steps and obtain relevant results for a specific sequence. This service allows for great flexibility
.
Typical uses of 31 services can include functions such as erasing memory, resetting defined data, overriding normal service control policies, and controlling changes in ECU values over time. Can start specific sequence, stop running this specific sequence, request operation result by 31 services
. This service was often used in the past when the ECU was doing software modification and updating, and it was used to check whether the flashing conditions were met, the integrity of the transmitted data,
and the independence test.
31 Service sub-function:
Service 31 01: start to execute the routine.
Service 31 03: Request routine result.
Service 31 02: Stop running routine.
Pay attention to the order of requests here, otherwise NRC=24

Upload and download functional unit (Upload & Download)

$34 - Request Download (RequestDownload)

This service initiates data transfer from the tester to the ECU. When the ECU is ready to receive data from the tester, it sends a positive response with the available block size (number of data bytes per transfer data request) for subsequent data transfers

$35 - Request Upload (RequestUpload)

This service initiates the data transfer from the ECU to the tester. When the ECU is ready to send data to the tester, it sends an affirmative response with the block size (number of data bytes per transfer data request) for subsequent data transfers

$36 - Data Transfer (TransferData)

This service is used to transfer data between the tester and the ECU (download) or between the ECU and the tester (up). If more than one transferData request is required to transfer data, use blockSequenceCounter to count the number of transfers. Counters allow repeated transfers of blocks after transfer corruption. Therefore, in case of communication problems, the complete data does not have to be transmitted again

$37 - Request to exit transfer (RequestTransferExit)

This service is used to terminate the transferData service. A complete data transfer starts from the requestDownloadrequestUpload service, continues by several transferData services, and is completed by the requestTransferExit service.

$38 - Request File Transfer (RequestFileTransfer)

NRC Negative Response Codes:

insert image description here

addressing mode

UDS diagnostic service is a language for communication between people or devices and ECU controllers. There are often many ECU devices on the bus. As a diagnostic device, it can communicate with all ECUs or specify a certain ECU to communicate separately. Therefore, there are two addressing methods: Functionally Addressed and Physically Addressed.

Functional addressing:

That is, the broadcast diagnostic request Request, while waiting for the ECU on the bus to give a response.

Physical addressing:

Specify to send a specific diagnosis request Request, and wait for the response from the specified ECU.

Basic format of Request and response

A complete diagnostic service includes request and response, and some diagnostic services also include some sub-services, namely sub-functions. Diagnosis After the client sends a diagnosis request to the server, the server will check a series of conditions. If the conditions are not met, it will reply the corresponding negative response code (Negative Response Code NRC), which is used to indicate the reason for the request failure. The reply at this time is called Negative Response. If the checked conditions are all satisfied, but the service has not been processed within a predetermined time interval, a response of NRC 0x78 can be set to reply, that is, response pending. After the service is completed, a positive response (Positive Response) will be received.

The general reply process on the server side is as follows:

insert image description here

The server-side response process to the request with sub-services is as follows:

insert image description here

The following figures show the general formats of the UDS service's Request with sub-services, Request without sub-services, Positive Response and Negative Response.

The general format of a Request with subservices:

insert image description here

The general format of a Request without subservices:

insert image description here

The general format of a Positive response:

insert image description here

The general format of Negative response:

insert image description here

Among them, SID is the ID number of the service, and the Positive Response SID of the same service = Request SID + 0x40. The SID of the Negative response is 0x7F.

Services Supported by Different Sessions

Not all services are only active under one session, so there is a concept of session priority. The following figure lists the list of services supported under different sessions:

insert image description here