CAN总线的通信帧主要是用于正常工作时的信号传输。而CAN总线的诊断帧主要是用于售后故障检测和生产下线配置。

虽然CAN诊断帧的数据链路层是基于通信帧，但是由于诊断的功能不同，传输的数据内容不同，导致CAN诊断帧的分类方式也不同。

诊断帧有两种分类方式，按照寻址方式可以分为物理寻址和功能寻址，按照帧类别可以分为单帧和多帧。

1.物理寻址与功能寻址

正常通信时，车辆中所有的CAN节点是多主的关系，大家都在并行工作。而诊断是在特定情况下使用，需要先通过诊断设备（客户端）向目标ECU发出诊断请求，目标ECU（服务器）收到请求后才能做出响应，发出需要的数据信息。

诊断总线拓扑图

诊断根据功能的特点，有时需要对所有的ECU节点进行诊断服务请求（如检查所有故障），有时需要对单个ECU进行诊断服务请求（如检查某个ECU的故障）。

诊断设备与单个ECU进行点对点的诊断操作时，需要使用物理寻址；诊断设备与所有ECU进行点对多点的诊断操作时，就需要使用功能寻址。

1.1功能寻址

什么情况下需要进行点对多点的操作，也就是使用功能寻址呢？

比如在不知道车辆当前的基本状态，需要判断所有的ECU节点是否正常时，可以对所有的ECU先进行诊断会话服务请求，根据各个ECU的不同响应就可以判断出ECU是否正常。

这就像是在医院看病等待叫号时，假如还有10个号在等待，护士先统一问一声：“已经领号的人都在吗？”如果有10个人都回答了，那就是各个人（ECU）都正常；如果只有9个人回答，说明有一个人（ECU）不正常，那就要查看一下那个人是出现了什么问题。

没有响应的ECU要及时查找

再举个例子，比如对整车进行故障检测时，通常先对所有的ECU节点进行故障码读取（功能寻址），看看哪些节点有异常，有了初步结果后，再针对有异常的ECU进行单独的诊断检测（物理寻址）。

如果一开始就单独的对每个ECU进行故障检测，会耗费大量的时间，先统一检测可以加快诊断速度。

这就像是进入医院的大厅后，可以先对所有人进行红外线体温筛查，发现有发热的人后再进行单独的详细检查，否则所有人都同时进行详细检查，浪费了宝贵的检测仪器资源，也延长了等待时间。

统一检测（功能寻址）与个别检测（物理寻址）

诊断仪通过功能寻址方式发送请求报文时，同一网络中支持功能寻址的所有ECU都需要回复响应报文。

1.2物理寻址

物理寻址就是诊断仪与单个ECU之间的专向诊断。当诊断仪明确的要对某个ECU进行检测时，就会使用物理寻址，比如只检查BCM的版本信息时，就会使用BCM专用的物理地址。

诊断仪通过物理寻址方式发送诊断请求报文时，只有对应地址的ECU可以回复响应报文；

1.3示例

ECU收到诊断请求后，会通过诊断报文的ID来区分是物理寻址还是功能寻址，一般功能寻址的信号ID固定为0x7DF，而物理寻址的消息ID为客户自定义，每个ECU都不一样。

假如整车同一网络中有ECU1、ECU2和ECU3共三个节点，它们的物理请求报文ID分别为0x701、0x702、0x703，响应报文地址分别为0x70A、0x70B、0x70C。

通过物理寻址对ECU1进行会话服务请求的诊断数据如下：

诊断会话控制(10)服务-物理寻址

其中的0x701是ECU1对应的物理请求地址，所以网络中只有ECU1(70A)做出诊断响应。

通过功能寻址对所有ECU进行会话服务请求的诊断数据如下：

诊断会话控制(10)服务-功能寻址

其中的0x7DF是CAN网络的功能地址，所以网络中所有的ECU（ECU1、ECU2和ECU3）都做出诊断响应。

UDS中的大多数诊断服务既可以使用物理寻址也可以使用功能寻址，但是某些服务只能使用物理寻址，不能使用功能寻址。

比如安全访问Security access、通过标识符写数据WriteDataByIdentifier、输入输出控制InputOutputControlByIdentifier、例程控制RoutineControl等。这些服务都是要对单一的ECU进行专用的特殊操作，只能使用物理寻址。

这就像是医院里护士可以叫所有的人都去红外线仪器旁边测体温（功能寻址），也可以按编号一个一个的去测体温（物理寻址），虽然这样时间会长一些，但是不影响测体温的需求（诊断服务）。

但是某些操作，比如核对病人的姓名和电话就必须一个一个的沟通核对，不能所有人一起核对，那样就乱了；尤其是对病人进行输液，更是要根据每个人的具体情况输入对应的药物（写入参数），否则会产生混乱。

不同ECU需要写入的参数不同

总之，物理寻址的功能是最全的，在ECU的资源不足的情况下，有时可能不支持功能寻址，但是只要支持物理寻址，基本的诊断功能就不受影响。

2.单帧与多帧

2.1单帧

CAN总线正常工作时的通信帧，每一帧数据字节最大是8个字节。诊断帧中的一帧也是8个字节，但是这8个字节不全是数据信息，还有地址信息AI和协议控制信息PCI，这些信息会占用1-2个字节（正常地址占用1个字节，扩展或混合地址占用2个字节），所以一个诊断帧中最多可以传输6或7个数据字节。

当需要传输的数据长度不大于6或7个字节时，只要一个诊断帧就够了，这种类型的诊断帧称为单帧SF（Single Frame）。

大多数的诊断服务只需要单帧就够了，使用单帧的诊断服务可以是诊断仪向一个节点发送（1对1），也可以是诊断仪向多个节点发送（1对多），这个机制与前面的功能寻址类似。

单帧的收发

2.2多帧

诊断帧由于功能的需要，有时需要传输大量的数据（参数读写或数据下载时），7个字节是不够的。

当数据长度大于6或7个字节时，单独的一帧传不完，需要很多帧一起组合才能传输完成，这种类型的诊断帧称为多帧MF（Multiple Frame）。

多帧中第一个传输的帧叫首帧FF(First Frame)，后面接着传输的数据帧叫连续帧CF(Consecutive Frame)。

为什么要把第一帧单独命名，它跟后面的连续帧有什么不同吗？

之所以首帧要单独定义，是因为首帧中除了常规数据，还包括了要传输的数据总长度。

除了首帧和连续帧外，多帧中还有一个流控帧FC（Flow Control），这个流控帧中的流就是指数据流，流控帧的意思就是要对数据流量的多少进行控制。

发送数据的多少不是根据发送节点的功能需要确定的吗，为什么要进行控制呢？

这是因为不同接收节点的能力不同，发送节点的需求，接收节点不一定都能满足。

流控帧的目的就是让接收节点把自己具备的接收能力及时通知给发送节点，接收能力包括每次最多能接收的数据帧的数量（BlockSize）和两个连续帧间的最小的间隔时间（STmin）。

节点的接收能力不同是因为不同控制器的存储容量和处理速度不同，有的存储容量大，处理速度快，有的存储容量小，处理速度慢。

容量有限，接收不了太多

首帧是指发送的第一帧，会告知接收方数据是多帧，然后接收方会回一帧流控帧，告知发送方是否可以接着发送，并且告知接收方一次最多能接收的数据量，以及发送方接下来发送的数据帧(连续帧)之间的时间间隔要求。

多帧的收发过程

首帧、连续帧和流控帧是如何区分的呢？

前面说过，CAN通信帧一帧可以发送8个字节的数据，这8个字节称为数据场。诊断帧单帧也是发送8个字节，但是这8个字节不都是数据，而是由地址信息AI、协议控制信息PCI和数据场DF组成的。

诊断帧的组成

地址信息AI包括源地址SA、目标地址TA、地址类型TAtype和可选的地址扩展AE。

地址类型TAtype是目标地址TA的扩展，用来表示物理地址还是功能地址。

物理地址可以支持所有的诊断报文类型，而功能地址只能支持单帧SF报文。

地址扩展AE用于在很大的网络中扩展地址，只在报文类型为远程诊断时使用。

比如正常地址的所有AI信息都包含在CAN ID中。

CAN诊断帧的参数分布-正常地址

扩展地址中的TA信息是放在了Byte1中，占用了一个数据字节。

CAN诊断帧的参数分布-扩展地址

混合地址是指报文类型为远程诊断时的地址，AE信息放在了Byte1中，也是占用了一个数据字节。

CAN诊断帧的参数分布-混合地址11位CAN ID

而不同的诊断帧类型，是通过CAN报文的数据场中协议控制信息PCI（Protocol control information）来区分的。

PCI 字节定义

PCI的长度不是固定的，根据不同的帧类型，长度可以为1-3个字节。

PCI字节定义表格中的各个参数含义如下：

DL：有效数据的长度，单帧时它的长度是4位,有效数值范围是1-7（其中7只用于正常地址）。

首帧时它的长度是12位，可以表示7-4095个字节（这里的7只用于扩展或混合地址）。

SN：连续帧的序列号，有效数值范围是0-15，但是由于首帧SF默认的SN是0，所以首帧之后的连续帧CF中的SN应该是1，每次加1，后续超过15时，会重新从0开始计数。

SN定义

FS：数据流的状态，用来表示发送方是否可以继续传输报文。

0表示接收方已做好准备，可以继续发送；

1表示接收方还没准备好，需要让发送方等待，只有发送方收到下一个允许继续发送的流控帧FC时才能发送；

2表示数据溢出，发送方需要停止发送。这里的数据指的是首帧SF中的DL值超过了接收方的缓存能力，所以数据溢出只会出现在首帧SF之后的第一个流控帧FC。

通过流控帧中的FS，接收节点就可以通知发送节点是继续发送、等待，还是因溢出而停止发送。

FS数值定义

BS：块容量，有效数据范围00-FF，表示接收方一次能接收的数据最大量；其中的00表示发送方可以连续的把所有的连续帧发送完，中间不需要停顿等待流控帧FC的指示。BS实际上就是表示每块（组）连续帧的数量，最后一块可能会小于BS值。

BS数值定义

STmin：表示两个连续帧之间的最小时间间隔。

STmin数值定义

比如STmin=10时,就表示两个连续帧的时间间隔不小于10ms。

使用多帧的诊断服务只能是诊断仪向一个节点发送，这个机制与前面的物理寻址类似。

3.示例

在车辆诊断中，有时需要读取车辆的软件版本号、硬件版本号、VIN码等数据，用来检查控制器的版本和车辆型号等信息，读取的过程是通过UDS诊断服务中的“0x22通过标识符读数据服务”来实现的。

我们以一个多帧数据传输的示例-读取VIN码来回顾下诊断帧的类型和网络层数据传输协议。

读取VIN码的数据标识符（DID）是F190，通过诊断仪Tester向控制器ECU发起读VIN码的请求和数据传输过程如下：

读取过程说明：

1.首先诊断仪Tester向ECU发起读（22）DID（F190）的请求。第一个字节PCI=03,0表示此帧是个单帧，3表示数据有3个字节（22 F1 90）；

诊断请求

2.由于VIN码是17个字节，超过了单帧能发送的最多7个字节限制，所以需要采用多帧发送，ECU先发送多帧中的首帧。前两个字节PCI=1014，其中1表示首帧，014表示字节数，转换为十进制数是20。

多帧-首帧

3.诊断仪Tester向ECU发出流控帧，PCI信息为30 00 0A，第一个字节中的3表示流控帧，0（FS）表示接收已做好准备；第2个字节00（BS）表示发送方可以连续的把所有的连续帧发送完，中间不需要再等待流控帧了。第3个字节0A（STmin）表示两个连续帧之间的最小时间间隔为10ms。

多帧-流控帧

4.ECU向诊断仪Tester发第1个连续帧，PCI信息为21，其中的2表示连续帧，1表示SN号序列号是1，这里要注意，由于首帧SF默认的SN是0，所以首帧之后的第一个连续帧CF中的SN应该是1，而不是0。

多帧-连续帧1

5.ECU继续向诊断仪Tester发第2个连续帧，PCI信息为22，其中的第1个2表示连续帧，第2个2表示SN号序列号是2。至此，VIN的数据全部发完。

多帧-连续帧2

有的同学可能有个疑问，从ECU发送的数据可以看出，读取到的VIN数据是01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11共17个数据。为什么ECU在首帧中发出的DL长度是20个（14）呢？

这是因为首帧中的62 F1 90这三个字节是诊断服务22的响应报文数据，其中的62是肯定响应SID，F1 90是DID。这三个字节虽然不是我们车辆最终要查看的应用数据，但是也是需要在网络中传输的数据，所以也要计算在多帧的数据长度参数DL中！