UDS Service Basics Part 22

UDS Diagnostic Service Basics Part 22

foreword

22 service, as the basic service of the diagnostic service, can be simply understood as an external interface for reading ECU data, which can obtain relevant status information inside the software in real time.

Since this article is an introduction to the basics, Xiao T will still ask you questions about 22 diagnostic services?

• 22 What is the practical use of the service?
• 22 What are the application scenarios of the service?
• 22 What is the diagnostic and treatment format of the service?

In this article, let's explore and answer these questions together. To make it easier for everyone to understand, the following is an outline of the topics of this article:

---

text

service function

Functional description

According to the ISO14119-1 standard, the diagnosis service 22 is mainly used for the Client to read relevant data from the Server (ECU) through DID. These data can be input and output digital signals, analog signals, internal data and other system status information.

Application Scenario

Generally speaking, for 22 diagnostic services, the main application scenarios are as follows:

• Read the serial number, version number, etc. of the current ECU;
• After the calibration is successful, read the internal calibration results, etc.;
• Read the Session, internal state, Snapshot Data, etc. where the current ECU is located;
• Other occasions that need to read internal related parameters;

The application scenarios mentioned above are relatively common. In addition, there are of course many application scenarios for ECU internal testing, which will not be listed here.

Request for service

A service request is a diagnostic service instruction sent by the Client to the Server . Among them, Client can be understood as Tester, and Server can be understood as ECU node.

request format

According to the ISO14229-1 standard, as shown in Figure 1 below:

Figure 1 22 diagnostic service request format

The parameters in Figure 2 below are explained as follows:

Figure 2 22 request format description

Summary of common DIDs

According to the ISO14229-1 specification, many DIDs that can only be used in specific occasions are defined, which means that everyone cannot use DIDs at will. When using DID Numbers, the requirements of 14229 should be fully considered to prevent the phenomenon of arguing with customers.

As shown in Figure 3 below, the more common DID types and their meanings are briefly listed:

Figure 3 Summary of common DIDs

request instance

Single DID Format

Taking reading a single DID F1 90 (VIN code) as an example, the corresponding diagnostic request example is shown in Figure 4 below:

Figure 4 22 service ticket DID diagnosis request example

Special attention should be paid to the fact that there is no subfunction in 22 diagnostics.

Multiple DID Format

Since there is a single DID read, there is naturally the operation of multiple DID read data, as shown in Figure 5 below, which is an example of 22 diagnostic service requests for reading multiple DIDs ( 01 0A + 01 10 ) at the same time:

Figure 5 Example of a 22-service multi-DID diagnostic request

Of course, when multiple DIDs are read, it means more than 22 diagnostic read requests of more than one DID, because the number is not limited.

When it comes to multi-DID reading of 22 services , the use of Composite DID can also be expanded here , that is, by reading a DID, multiple DIDs that are mapped to the DID can be read together. The advantage of this is that it can The values ​​of other existing DIDs can be obtained at one time through a certain DID, and its software implementation can also be realized through configuration.

service response

The service response is the response of the Client to the Server diagnosis request.

positive response format

As shown in Figure 6 below, it is the positive response format of the 22 diagnostic service:

Figure 6 22 diagnostic service positive response format

As can be seen from the above figure, the positive response of the 22 diagnostic service consists of the following two parts:

• Response ID: This parameter is fixed at SID+0x40 = 0x62;
• DID: This parameter indicates the identifier of a certain data. The figure shows that there can be multiple DIDs, and the number of specific DIDs should be consistent with the DID of the diagnosis request;

Positive response instance

Single DID Format

As shown in Figure 7 below, it is the positive response corresponding to the above single DID ( F1 90 ) request example:

Figure 7 22 Diagnostic Service Ticket DID Positive Response Example

Multiple DID Format

As shown in Figure 8 below, it is the positive response corresponding to the above multi-DID ( 01 0A + 01 10 ) request example:

Figure 8 22 Diagnosis Service Multiple DID Positive Response Example

As can be seen from the figure above, there are multiple Numbers of two DIDs and subsequent data values ​​in the multi-DID diagnosis reply.

Negative Response NRC

NRC Code

In most cases, the server will give a positive response to the client's request. For example, it is necessary to ensure that the whole vehicle is in a safe state before restarting. Request, then the Server needs to tell the Client the reason for the unsuccessful execution in some way, so as to investigate the problem until a positive response is obtained.

Therefore, ISO14229-1 provides a unified diagnostic negative response diagnostic format for all diagnostic services: 7F +SID + NRC .

The full name of NRC is Negetive Responce Code, and each NRC has a unique meaning to represent the cause of the current diagnostic request error. Of course, the NRCs supported by each diagnostic service are different. For the specific supported NRCs, please refer to the ISO14229-1 standard document. For the 22 services, the supported NRCs are shown in Figure 9 below:

Figure 9 22 service NRC Code

• For example, when trying to read the DID value of F190 and the current vehicle speed condition is not satisfied, the Client sends a diagnostic command "22 F1 90" to request the Server to read the data, and the Server will reply "7F 22 22 " to tell the requester to read the data currently The condition of is not satisfied, please check the condition of reading the DID again.
• When the length or format of the sent message is incorrect, the Server will reply " 7F 22 13 ";
• When too many DIDs of the diagnostic request exceed the limit of the transport layer, the server will reply " 7F 22 14 ";
• When the diagnostic request DID does not exist or is not supported in the current Session, the Server will reply " 7F 22 31 ";
• When the server is in the security lock state before the reset occurs, the server will reply " 7F 22 33 " at this time ;

NRC priority

Which NRC should reply when multiple conditions are not met in the diagnostic request? There is no doubt that the concept of NRC priority needs to be introduced at this time. The following is the NRC priority of diagnostic service 22 for your reference:

Figure 10 22 service NRC priority

NRC priority

Which NRC should reply when multiple conditions are not met in the diagnostic request? There is no doubt that the concept of NRC priority needs to be introduced at this time. The following is the NRC priority of diagnostic service 22 for your reference:

Figure 10 22 service NRC priority

---

For more exciting content, please pay attention to the following public account "My opinion on ADAS and ECU!"