首先给出ISO15765-4协议中对数据发送的要求

从这个协议中我们知道了几个知识点：

① ISO15765-4是一个基于CAN总线的诊断协议，它与排放有关。

② ISO15765-4有可能是一个CAN标准帧（11-bit），也有可能是一个CAN扩展帧（29-bit）。

③ ISO15765-4的波特率有可能是500kbps，也有可能是250kbps。

④ ISO15765-4的CAN通信是有请求，才会有回应的。并不是像J1939那样广播式的。

⑤ISO15765-4和ISO15031-5（应用层）一起构成完整的功能。

然后讲下怎么脱离枯燥的理论来感受ISO15765-4协议。我们在这里以标准帧来举例。

    （ISO15765-4协议中标准帧的帧ID）

上面这个图说明了ISO15765-4协议的帧ID有0x7DF、0x7E0、0x7E8、0x7E1、0x7E9等等（0x在这里表示16进制）。看描述就能得知，0x7DF是外部测试设备发出的请求帧，是一个功能寻址，广播的，也就是说，如果诊断仪Tester发出了7DF，所有的ECU都要进行回复Response。

0x7E0是物理寻址Request，由诊断仪Tester发出，有针对性的，1对1，只和ECU1号有仇。0x7E8是1号ECU发出的回应帧，功能寻址和物理寻址都支持。也即对一个ECU来说，它包含3个帧ID。一个是功能寻址请求ID，一个是物理寻址请求ID，一个是回复Response ID。

好的，我们好像得到了一些线索，这些帧ID是ISO15765-4协议的显著特征。

要理解一个协议最好的方法是什么呢？拿着协议，然后找到一个满足这个协议的设备把玩一下。

在这里给出一个很久以前买来的15765协议,供参考(参考附件-可下载):

    （部分ISO15765-4协议内容）

在上面的图中我们可以看到，我们的老朋友7DF和7E8，这两个是帧ID，也就是CAN总线的“地址”。这个“xx”是可选字节，根据你不同的需求，在这个位置填入不同的数据。

下面用车速来举一个简单易懂的例子。

    （车速ISO15765-4协议中的表示方法）

我们可以看到车速的可选字节是“0D”，后面的意思是：Byte3（从左往右数第四个）的数值表示了车速。

现在我们验证一下，选用广成科技USBCAN-II Pro分析仪，将两个通道短接在一起。之后选择500k波特率，进入ECANTools软件，选择2通道，将0x7E8填入帧ID一栏，将06 41 0D 7B 00 00 00 00依次填入帧数据一栏，之后点击发送。在OBD II界面中我们可以看到仪表盘发生了转动。这说明我们发送了正确的数据。我们看到仪表盘显示的车速是123，怎么来的呢？帧数据的第四个字节0x7B转成16进制就得到了123。

    （填入正确的数据）

    （车速发生了变化）

以上是我们的一个简单的模拟。并不是车上真实发生的事情，只是帮助您理解协议。

那这个OBD II界面在真实的试车环境下如何使用呢？这个界面的正确用法是，将CAN线（1通道）接入到车辆CAN总线上面。如果该车辆满足ISO15765-4协议，那么点击“循环获取实时数据”，软件将自动发送帧ID为0x7DF的请求数据。要注意，第三个字节是在变化的。

     （发送了很多帧ID为0x7DF的请求数据）

从上面的图中我们可以看到，我们发出了对“0D”这个可选字节的请求。相应的车辆将会把“0D”的这个信息回应给我们。

我们模拟了一下，真实车辆环境下还是有很多数据回应的。解读下上面的图，0x7E8表示这数据是1号ECU作出的回应。

06在这里作为网络层数据，代表这是一个单帧，有效数据包含6个字节（不算06自己）。

如果对这个CAN的网络层感兴趣可以参考：

UDS网络层/TP层（ISO 15765-2）的解读

41是应用层数据（ISO15031-5协议），它是由0x01服务再加上0x40得来的，表示我确认了Tester（诊断仪）发出的01服务。

0D代表我这一包数据是代表车速，58代表真实的车速值是0x58，也就是88。