ISO14229 Series II: Diagnostic instruction format and related concepts

Author: Autogeek

Original link: http://www.cnblogs.com/autogeek/p/4458658.html

1. Simple communication mechanism

In fact, the mechanism of diagnostic communication is very simple, you can analogy client-server communication mode, that is, the client sends the request, the server receives the request for processing, and then sends the response to the client. However, the diagnostic protocol has its own characteristics, which specifies the format of the request and response, and the format to be checked when the request is received. At the same time, due to different addressing methods, there is no sub-function support, etc., will also affect the request and response processing methods and results. I will analyze the specific situation below, as far as possible to achieve a concise introduction.

2. Request 2.1 Basic format

To sum up, the diagnostic request format is nothing less than the following 2 types:

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

That is, there is no sub-function difference. Among them, I have also attributed did to parameter

2.2 with Sub-function

Before you introduce the request with Sub-function, let's first look at how sub-function is defined. is cut from the ISO14229, it is the definition of sub-function.

It is noteworthy that bit 7, which is literally used to indicate whether to suppress positive Response. Indeed, it is intended to mean that when bit 7 is 1 (1 = ' true '), the positive Response of the request is suppressed, that is, the positive Response is not sent; when Bit7 is 0 (0 = ' False '), the positive response of the request is not suppressed and sent normally. In addition to the bit 7,sub-function have different values, the specific values and meanings are described in the protocol for each service interpretation.

2.3 Without Sub-function

According to the instructions of 2.2, without sub-function service, take parameter. Parameter can be did, can be an input parameter, can be a custom value, and the number of bytes depends on the specific requirements. Generally in the agreement will have a table, when the specific problems encountered, you can check the table to determine.

3. Response

Generally speaking, response will be sent after a service is request and executed, successful words positive response, failure to send negative response, but there are exceptions, such as Ecureset, He asked to send response first, and then to perform the specific reset, because if reset first, then the ECU communication module shut down, is unable to send out response. In general, as in this particular case, the Protocol will be annotated when describing a specific service.

3.1 Positive Response

Basic format:

<SID+0x40> + <Sub-function> + <Parameter>

<SID+0x40> + <Parameter>

It is important to note that the first byte is made up of SIDS and 0X40, and as to why this should be done, only the protocol is so specified, as long as the positive response, the first byte is to be the value of the corresponding SID plus 0x40 composition. Here the parameter item is optional, depends on the agreement stipulation.

For example, the service of Session control:

Send:10 (byte1 10 is Sid,byte2 01 is sub-function, and the bit 7 is false)

Receive:50 (Byte1 is Sid+0x40,byte2 is sub-funtion)

Give an example without sub-function, such as the Readdatabyid service:

Send:22 F1 (Byte1 is Sid,byte2 and Byte3 is did, can be regarded as parameter of one)

receive:62 F1 (byte1 62 is Sid+0x40,byte2 and Byte3 is did,byte4 is read data)

Whether physical addressing or functional addressing, for positive response there is no impact, only need to pay attention to sub-function in the bit 7 suppressposrspmsgindicationbit is 0 or 1, if 0 is false, Then normal send, if 1 is true, then do not send response. If there is no subfunction at all, then nothing to consider, it must be sent positive response.

3.2 Negative Response

Basic format:

<0x7F> + <SID> + <NRC>

Looks relatively simple, the format is fixed, as long as the negative Response, the first byte must be 0x7f, the second byte copy the original SID, the third byte is the error response code, indicating the specific error response reason, the NRC can be found in the protocol, And the NRC supported by different services is also provided.

Or take the session control of the service to illustrate:

Send:10 05 (now Sun-function becomes 05, assuming the system does not support this sub-function)

receive:7f (7F refers to the error response, 10 for sid,12 is the NRC, check the agreement that its reference sub-function not supported this error)

The format is finished, to see what the difference is between the negative response and the physical addressing and functional addressing.

First in the case of physical addressing, as long as the negative response should be sent in accordance with the prescribed format. In the case of functional addressing, a little special, for the NRC is 0x11 (service not supported), 0x12 (subfunction not supported), 0X31 (Request out of range) of the three cases, Functional addressing is not sending response.

4. Check policy for Request

Here is a flowchart to show how the ECU checks his legitimacy after receiving the request and whether it is a positive response or a negative response, sending or not sending. This is just a demonstration of the most basic steps, as well as specific criteria that are relevant to each service and need to be discussed in conjunction with specific requirements.

ISO14229 Series II: Diagnostic instruction format and related concepts