ISO14229系列之二：诊断指令格式和相关概念(转)

清疚 2022-05-24 11:13 136阅读 0赞

作者:autogeek  
原文链接:[http://www.cnblogs.com/autogeek/p/4458658.html][http_www.cnblogs.com_autogeek_p_4458658.html]

### 1. 简单的通信机制 ###

其实诊断通信的机制很简单，可以类比client-server通信方式，即客户端发送request，服务器收到request之后进行处理，然后向客户端发送response。但是，诊断协议有自己的特色，它规定了在request和response的格式，在收到request的时候要做格式的检查。同时由于寻址方式的不同，有无sub-function的支持等，也会影响request和response的处理方式和结果。下面将我就具体情况分析，尽量做到简介明了。

### 2. Request ###

#### 2.1 基本格式 ####

归纳起来，诊断的request格式无非以下2种：

即有无sub-function的区别。其中，我把DID也归为Parameter

#### 2.2 有sub-function ####

在介绍有sub-function情况的request之前，首先要了解一下sub-function的定义方法。下图是从ISO14229中截来的，它是对sub-function的定义。

![这里写图片描述][70]

值得注意的是Bit 7，从字面上来看它用来指示是否要抑制Positive Response。的确，它的目的就是这个意思，当Bit 7为1（1 = ‘true’）时，对该request的Positive Response要被抑制，即不发送Positive Response；当Bit7为0（0 = ‘false’）时，对该request的Positive Response不被抑制，正常发送。除了Bit 7，Sub-function有不同的值，具体的值和含义在协议中对每个服务的解释时都会有介绍。

#### 2.3 不带sub-function ####

根据2.2的说明，不带sub-function的服务，就带parameter。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数目也是视具体要求而定。一般在协议内都会有表格，当遇到具体问题时，可查表确定。

### 3. Response ###

一般来讲，response会在一个服务被request且执行之后发送，成功的话就发positive response，失败的话要发negative response，但是也有例外的时候，比如ECUreset，他要求先发送response，然后再去执行具体的reset，因为如果先reset，那么ECU的通信模块shut down，是无法发送出去response的。一般像这种特殊情况，协议会在描述具体服务时标注出来。

#### 3.1 Positive Response ####

基本格式：

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

其中要注意第一个字节是由SID和0x40的和构成，至于为什么要这样做，只能说协议就是这么规定的，只要是Positive的response，其第一个字节就是要由相应SID的值再加上0x40构成。这里的Parameter项是optional的，具体要看协议规定。

比如session control的service：

Send：10 01（byte1的10是SID，byte2的01是sub-function，且可知Bit 7是false）

Receive：50 01 （byte1是SID+0x40，byte2是sub-funtion）

再举个不带sub-function的例子，比如ReadDataById这个service：

Send：22 F1 86（byte1是SID，byte2和byte3是DID，可视为parameter的一种）

Receive：62 F1 86 01（byte1的62是SID+0x40，byte2和byte3是DID，byte4是读到的数据）

不论是物理寻址还是功能寻址，对于Positive Response来说都没有影响，只需要关注sub-function中的Bit 7 suppressPosRspMsgIndicationBit是0还是1，如果为0即false，那么正常发送即可，如果是1即true，那么就不发送response。如果根本没有subfunction呢，那么什么都不要考虑，肯定是要发送positive response的。

#### 3.2 Negative Response ####

基本格式:

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

看起来比较简单，格式比较固定，只要是Negative Response，第一字节就一定是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因，这个NRC可以在协议中查到，并且不同的服务所支持的NRC也有规定。

还是拿session control 这个service来举例：

Send：10 05（现在sun-function变为05了，假定系统不支持这个sub-function）

Receive：7F 10 12（7F即指代错误响应，10为SID，12是NRC，查协议可知其指代sub-function not supported 这个错误）

格式讲完了，来看看在物理寻址和功能寻址情况下，Negative Response分别有什么区别。

首先在物理寻址情况下，只要是Negative Response就应该按照规定格式发送。而在功能寻址情况下，有一点特殊，对于NRC为0x11（service not supported）、0x12（subfunction not supported）、0x31（request out of range）这三种情况，功能寻址是不会发送response的。

#### 4. Request的检查策略 ####

下面用一张流程图来展示收到request之后ECU如何检查他的合法性，并确定是正响应还是负响应，发送还是不发送。这里只是展示最基本的步骤，还有具体的和每个服务相关的条件判断，需要结合具体需求来讨论。  
![这里写图片描述][70 1]

[http_www.cnblogs.com_autogeek_p_4458658.html]: http://www.cnblogs.com/autogeek/p/4458658.html
[70]: /images/20220524/abc9ce2b59b94ca5ac6bdbdbb57b60a3.png
[70 1]: /images/20220524/134da17ee9c8448597522cfba0915190.png