简单的通信机制

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

Request

基本格式

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

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

<SID>+<Parameter>

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

有sub-function

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

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

不带sub-function

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

Response

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

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-function）

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

Send：22 F1 86(byte1是SID,byte2和byte3是DID,可视为parameter的一种)

Recevie：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。如果根本没有sub-function呢，那么什么都不要考虑，肯定是要发送positive
response的。

Negative Response

基本格式：

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

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

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

Send：10 05（现在sub-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 suppored）、0x12（subfunction not supported）、0x31（request out of range）这三种情况，功能寻址是不会发送response的。

Request 的检查策略

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