单帧、首帧、续帧、流控帧-手把手分析报文

---

前言

在ISO 15765-2中对于网络层协议数据单元N_PDU有4种类型，分别为单帧SF、首帧FF、连续帧CF、流控帧FC，并且在帧格式上区分CAN和CANFD。

---

一、单帧 SF

0X 单帧（X代表包含的SF_DL数据长度信息），后续字节自动填充。
在清除DTC操作中，一般返回单帧结果：01代表只有一个数据，数据为54，后续字节自动填充AA。

二、首帧 FF

1X XX 首帧（X XX代表FF_DL数据长度信息），后续字节自动填充。
0EF表示数据长度为239，包括首帧上的6个和续帧每帧上的7个字节，下图绿色标注出的数据部分。

三、续帧 CF

2X 续帧（X代表SN序号信息）
注意： 首次续帧是0x21（通常记首帧为0x20）【原因：数据传输中，首帧SF数据作为第一个数据传输序列号SN为0】
最多16个续帧，溢出后从0重新开始。如下图，测试中，若续帧数量达到2F后仍有没有发完的续帧，则循环从20开始发送剩余的续帧报文。

四、流控帧 FC

3X 流控帧，X代表flow state，X = 0 继续发送；X = 1 等待；X = 2 溢出。

30：流控帧，继续发送
00：BlockSize(BS), 表示上位机收到流控帧后，可发送的连续帧数量。设置为0时，发送数量无限制。
14：STmin（ms）,表示上位机发送 连续帧之间的间隔，STmin可以为0、1，不能为0.5，接收方处理能力不足。

Q：这个STmin时间过大或为0有什么影响？
A：STmin为0发送过快，接收端处理不足，可能会导致丢帧。（依次发来1、2、3，2没从缓存中取出被3覆盖）；STmin发送过慢，会影响刷写效率。

Q：流控帧FC和第一个续帧CF之间也需要满足STmin时间要求吗？
A：受接收方处理能力的限制，STmin不能小于1，这也约束着发送方从收到FC到发出第一个CF的时间间隔也需要≥1ms

五、项目案例

在CAN故障注入测试DTC时，通过14服务清除DTC后进行短路故障制造，19服务读取DTC信息时，没有读取到期望DTC，直接判定为样件有bug。

定位分析发现，如上图在仿真发送19服务后，被测DUT回复首帧10，数据长度为0DB（219个字节），继续仿真发送流控帧FC，DUT回复续帧。可以明显看到DUT回复的数据没有219个字节。原因在于仿真发送的FC的BlockSize设置为08，导致只接受到8帧续帧，对于节点短路故障DTC认为ECU没有报出，这种情况是错误的。从首帧的数据长度DB（219）来看，数据量由于08限制，没有全部展示出。