In the previous article (Vehicle Network Test - UDS Diagnosis - Brief Analysis of Diagnostic Data), we introduced the data format of each service. The next section is to further introduce each service so that everyone can learn and understand; today we It is talking about session control, and it is also called session control in some places. Let’s briefly talk about this service below. If there is something wrong, please correct me.
1.10 Service Data Description
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 ECUQ node.
request format
As described in the 14229-1 standard, as shown in the figure below:
| A Data byte |
Parameter Name |
Cvt |
Byte value |
Mnemonic |
| #1 |
DiagnosticSessionControl Request SID |
M |
1016 |
DSC |
| #2 |
SubFunction = [ diagnosticSessionType ] |
M |
0016 to FF16 |
LEV_DS |
The parameters in the figure are explained as follows:
| parameter name |
Value (Hex) |
meaning |
| DiagnosticSessionControl Request SID |
10 |
Diagnostic session control SID, fixed at 10 |
| SubFunction = [ diagnosticSessionType ] |
00-FF |
Session type, such as default session 01, programming session 02, etc. |
10 Service Diagnosis Request Format Description
In the above figure, we mentioned 10 service session types, which can be mainly divided into six types:
- default_session (0x01) ;
- programming session (0x02);
- extended session (0x03);
- Security Diagnostic Session (0x04);
- Vehicle manufacturer custom session (0x40-0x5F);
- Component supplier custom session (0x60-0x7E)
Service Response
10 The service response is the response of the Client to the Server diagnosis request.
Affirmative response: (sessionParameterRecord is defined for each OEM)
The following figure shows the positive response format of 10 service diagnostics:
The specific meaning of sessionParameterRecord is shown in the following figure:
Negative answer:
In most cases, the server will give a positive response to the client's request, but as mentioned before, it is necessary to ensure that the whole vehicle is in a safe state before entering the programming session, such as the engine is turned off, the speed cannot exceed 3km/h, etc., or for To prevent requests not following the diagnostic request format, the Server needs to tell the Client the reason for the unsuccessful execution in some way so as to facilitate the investigation of 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 not the same, and the specific supported NRCs need to refer to the ISO14229-1 standard document. For 10 services, the supported NRCs are as follows:
| NRC |
Description |
Mnemonic |
| 0x12 |
sub-functionNotSupported This NRC shall be sent if the sub-function parameter is not supported |
SFNS |
| 0x13 |
incorrectMessageLengthOrlnvalidF ormat This NRC shall be sent if the length of the message is wrong |
IMLOIF |
| 0x22 |
conditionsNotCorrect This NRC shall be returned if the criteria for the request DiagnosticSessionControl are not met. |
CNC |
2.10 Service Introduction
As we all know, the biggest difference between automotive electronics and our consumer electronics is safety. The safety of automotive electronics runs through the entire design and development process, as well as the use of terminals. Then we will restrict its permissions for different users and different services. Therefore, session control comes from this. In the session control of 10 services, it is mainly divided into default session and non-default session, and non-default session will be used according to the actual needs of each OEM. However, some of the sub-services are tacit understandings that have been formed within the industry, namely the default session, extended session, and programming session; these must correspond to 01 sub-service, 03 sub-service, and 02 sub-service.
3. Session switching
The above figure is a graphical description of session switching defined in ISO-14229, but the specifications used within each company will further explain non-default sessions; several common rules:
1. Any session can be directly switched to the default session
2. Any session can be switched to its own session
3. Entering the default session will initialize all volatile configurations under reset non-default session