UDS Diagnosis Service Basics Part 2E
foreword
As the basic service in the diagnostic service, 2E service can be simply understood as an external interface for writing ECU data , which can obtain relevant status information inside the software in real time.
Since this article is an introduction to the basics, will Xiao T still ask you questions about 2E diagnostic services?
- What is the practical use of 2E services?
- What are the application scenarios of 2E services?
- What is the diagnostic service format of 2E 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 diagnostic service 2E is mainly used for the Client to write relevant data to the Server (ECU) through DID.
Application Scenario
Generally speaking, for 2E diagnostic services, the main application scenarios are as follows:
- Write relevant configuration information, such as the common VIN code, during the process of vehicle off-line;
- clear NVM;
- Reset the data that has been written into Flash;
- Other occasions that need to write 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:
The parameters in Figure 2 below are explained as follows:
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:
request instance
Taking writing DID F1 90 (VIN code) as an example, the corresponding diagnostic request example is shown in Figure 4 below:
service response
The service response is the response of the Client to the Server diagnosis request.
positive response format
As shown in the figure below, it is the positive response format of the 2E diagnostic service:
As can be seen from the above figure, the positive response of the 2E diagnostic service consists of the following two parts:
- Response ID: This parameter is fixed at SID+0x40 = 0x6E;
- DID: This parameter indicates the identifier of a certain data, and the DID of the reply should be consistent with the DID of the diagnosis request;
Positive response instance
As shown in Figure 7 below, it is the positive response corresponding to the above DID ( F1 90 ) request example:
Note: When the corresponding 2E service returns a positive response, it is generally necessary to ensure that the data has been successfully written into the NVM at this time. Of course, if the KL30 is powered, the power-off storage mechanism can also be adopted, but the premise is to follow the normal power-off sleep process or perform 1101 reset. action.
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. The supported NRCs for 2E services are shown in Figure 8 below:
- For example, when trying to write the DID value of F190 and the current vehicle speed condition is not satisfied, the Client sends a diagnostic command "2E F1 90" to request the Server to read the data, and the Server will reply " 7F 2E 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 2E 13 ";
- When the diagnostic request DID does not exist or is not supported in the current Session, the Server will reply " 7F 2E 31 ";
- When the server is in the security lock state before the reset occurs, the server will reply " 7F 2E 33 " at this time;
- When the memory address written by the 2E service is wrong, the server will reply "**7F 2E 72 **" 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 2E for your reference:
For more exciting content, please pay attention to the official account "My opinion on ADAS and ECU!"
