ISO14229 理解（一）

前言

ISO-14229用于汽车行业诊断通信的需求规范，它只规定了与诊断相关的服务需求，并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO-15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO-14229也称为UDS（Unified Diagnostic Services）统一诊断服务。

在ISO14229里，共有26个UDS服务：

---

用法

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

举例：

首先来看服务请求和响应格式，“请求”由client端发送给server，UDS规定使用1个byte来表示诊断服务，即所谓的Service ID,简称SID。请求报文里带有SID，根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”

诊断的request格式分2种，一种有sub-function的，一种没有sub-function的，上述例子是没有sub-function的。
当 UDS 服务支持 Subfunction 的请求和响应格式时：

“请求”为 “SID + 一个字节Subfunction + 具体的数据”，
肯定响应为“SID+40+Subfunction+具体的数据”，

而有的UDS服务里面是不支持 Subfunction，是支持DID的，DID是“数据ID”的意思，

它的请求格式为：“SID+具体的DID+数据内容”，
肯定响应为：“SID+40+DID+具体的数据”。

1. Request

基本格式：归纳起来，诊断的request格式无非以下2种：
即有无sub-function的区别。其中，我把DID也归为Parameter

<SID> + <Sub-function> + <Parameter> 
<SID> + <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；当Bit7为0（0 = ‘false’）时，对该request的Positive Response不被抑制，正常发送。除了Bit 7，Sub-function有不同的值，具体的值和含义在协议中对每个服务的解释时都会有介绍。

---

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

---

2. 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-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的。

Negative Response：
基本格式:

<0x7F> + <SID> + <NRC> //NRC：Negative Response Code（否定响应码）

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

下面这张图列举了部分原因代码，比如，如果ECU给出7F 22 13这个negative response，则说明22这个服务因为诊断请求数据长度不对的原因无法执行。

还是拿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的。

Request的检查策略