基于CAN总线实现的UDS诊断（DoCAN）

本文转自https://www.zhihu.com/people/zhang-ding-12-47/posts

作者：张丁
链接：https://zhuanlan.zhihu.com/p/37063798
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

感谢作者@张丁

之前写的UDS系列的文章介绍的都是应用层的诊断服务，不涉及下层的传输机制，本篇文章简要介绍一下基于CAN总线实现的诊断协议的传输层。本文以classical CAN为例，CAN FD原理类似，不单独讲述。

UDS定义的是诊断服务，属于应用层的内容，实现诊断通信的底层总线技术有很多，比如CAN，LIN，Ethernet，Flexray等，由于法规强制的OBD接口是CAN总线的，所以绝大多数场景中诊断都是基于CAN实现的。这就带来了一个问题，classical CAN总线物理层的每一帧只能传输8个字节，CAN FD第帧最多能传输64个字节，那么如果UDS产生的一条诊断命令超过了8个字节，在CAN总线上一帧是承载不了的，就需要进行分包，这也是DoCAN(Diagnose over CAN)要解决的最主要的问题。

为了实现诊断命令的分包传输，15765-2总共定义了4种类型的帧结构，每种帧结构以数据域的前两个或一个字节来标识（取决于帧类型）。这四种类型分别是：

1. SingleFrame
2. FirstFrame
3. ConsecutiveFrame
4. FlowControl

其中SingleFrame用于长度不超过7个字节的诊断命令或响应。FirstFrame，ConsecutiveFrame，FlowControl用于传输长度大于7个字节的诊断命令或响应。每个诊断帧的第一个字节的高4bit用于描述该帧的类型，即该帧属于上述四种中的哪一种。

传输层的4种帧结构

SingleFrame用于下面这种简单的场景：当诊断报文长度小于等于7时，再加上一个字节的PCI控制信息就是小于等于8，可以在一帧CAN报文上传输，所以不需要进行分包。此时数据域的第一个字节高4bit值为0000，标识这是一个帧SingleFrame，低4bit是SF_DL，即DataLength，描述后面有几个字节。如果有没有使用的字节，通常要用0x55或0xAA来填充，因为这两个值的二进制表述其实就是01010101和10101010，这样在CAN总线上可以让信号跳变得更频繁一些，不会出现长时间电平不变的情况。

SingleFrame的应用场景

如果一帧CAN报文无法承载一条诊断报文，则需要按照下面的流程进行分包发送：

诊断报文的分段发送

首先，发送端要以一个FirstFrame开启通信，告诉接收端还有后续的内容要发，FirstFrame使用前两个字节作为PCI信息，第一个字节高4bit为0001，标识这是一个FirstFrame，低4bit加上第二个字节用于描述总共发送的数据长度是多少（包括在FirstFrame中和在ConsecutiveFrame中的所有字节数）。

之后接收端发送FlowControl，告诉发送端能以什么样的速度来发送数据，FlowControl第一字节的高4bit为0011，低4bit为FS，即FlowStatus，第二个字节为BS(BlockSize)，第三个字节为STmin（SeperateTime）。FlowControl有0，1，2三种状态，分别命名为ContinueToSend (CTS)，Wait (WT)，Overflow (OVFLW)。如果允许发送端继续发送ConsecutiveFrame，则FlowStatus=0；若要求发送端等一会再发送ConsecutiveFrame，则FlowStatus=1，再下次允许sender发送ConsecutiveFrame时，receiver再发一个FlowStatus=0的FlowControl。如果receiver因为资源问题无法接收sender发送的数据，则发送一个FlowStatus=2的FlowControl。

BS指示sender一次可以发送多少个ConsecutiveFrame，当发送ConsecutiveFrame数量达到BS时，需要receiver再次以一个FlowControl开启下一波的ConsecutiveFrame发送。

receiver根据自身的接收和处理能力使用STmin指示sender在发送ConsecutiveFrame时最小的时间间隔是多少，从而实现流控制。

ConsecutiveFrame就是承载FirstFrame无法完全承载的剩余数据了，它使用第一个字节用作PCI，高4bit为0010，低4bit用于标识ConsecutiveFrame的序列号，从1开始，每发送一次ConsecutiveFrame增加1。

不分段传输的诊断服务举例：

request 02 10 03 55 55 55 55 55

response 06 50 03 00 32 01 F4 AA

这是一个请求进入extended session的最简单的诊断服务，请求和应答都是SingleFrame，加粗的0标识了SingleFrame，后面的2和6表示了这条诊断报文拥有几个字节的数据。

分段传输的诊断服务举例：

这是一个读取DTC的命令和应答。

03 19 02 08 55 55 55 55 （诊断仪发送的SingleFrame的request）

10 33 59 02 19 01 00 07 （ECU以FirstFrame开始传输的response）

30 00 00 55 55 55 55 55 （诊断仪发送的FlowControl）

21 09 03 05 02 09 05 04 （ECU发送的ConsecutiveFrame）

22 07 09 05 06 06 09 05 （ECU发送的ConsecutiveFrame）

23 08 03 08 07 01 05 08 （ECU发送的ConsecutiveFrame）

24 07 01 06 08 07 01 0C （ECU发送的ConsecutiveFrame）

25 08 07 01 0D 08 07 03 （ECU发送的ConsecutiveFrame）

26 07 09 08 01 01 09 09 （ECU发送的ConsecutiveFrame）

27 01 07 09 AA AA AA AA （ECU发送的ConsecutiveFrame，此时传输结束）

在这里我把所有传输层相关的PCI信息都用粗体标识了。

需要提一下的是，BS和STmin等于0时，表示接收端可以以最快的速度来接收数据，发送端可以一次发送的ConsecutiveFrame数量不受限制

最后

以上就是单纯手套为你收集整理的基于CAN总线实现的UDS诊断（DoCAN）的全部内容，希望文章能够帮你解决基于CAN总线实现的UDS诊断（DoCAN）所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。