ISO 15765-2帧格式详解：单帧、首帧、流控帧、连续帧及多帧传输

做车载网络诊断这些年，我收到最多的求助不是CAN收发器坏了，而是“诊断响应发不出去”或者“ECU收到请求不回”。查到最后，十次有七八次都栽在ISO 15765-2的传输层封装上：单帧、首帧、流控帧、连续帧这四种PDU的格式理解不到位，帧一多就出岔子。这篇文章想把ISO 15765-2（也就是AUTOSAR里CanTp模块要实现的那个协议）的帧格式从头到尾讲透，包括每种帧的字节布局、多帧传输时的流控机制、以及我在联调时踩过的一系列坑。无论你是在做UDS诊断、OBD排放，还是刷写Bootloader，理解这套帧格式都能让你少熬好几个通宵。

1. 为什么搞懂这四种帧格式是诊断开发的基本功

1.1 标准CAN数据场只有8字节，根本装不下一整条诊断数据

先算一笔账。标准CAN帧（Classical CAN）的数据场最多8个字节，而一条诊断报文往往不止8字节：读VIN返回17字节，读故障码可能要几十上百字节，复杂ECU的刷写动辄几千字节。8字节的“集装箱”装不下大件货物，协议就得设计一套“拆包-运输-拼包”的规则，ISO 15765-2干的就是这件事。

这套规则其实很朴素：小于等于7字节的直接用一帧发出去，这叫单帧；超过7字节就先发一个首帧告诉接收方“我这次总共要发多少字节”；接收方看情况回一个流控帧，告诉发送方“你现在可以发多少、每次间隔多久”；然后发送方用多个连续帧按顺序把剩余数据送完。

很多人刚开始学诊断，拿到Trace只看CAN ID和data，第一反应是“为什么ECU回的数据长得不一样”。比如0x7E8这条ID上一秒回的是03 62 F1 90，下一秒变成10 14 62 F1 90……其实第一个是单帧，第二个是首帧，数据场首字节就是协议控制信息（PCI），剩下的才是真正的诊断数据。搞不清PCI，就跟解不开密电码一样，什么排查都无从谈起。

1.2 在AUTOSAR协议栈里，帧格式对应的是CanTp模块

如果你做AUTOSAR开发，ISO 15765-2这套逻辑通常落在CanTp（CAN Transport Protocol）模块里，上面是PduR路由层，再往上是DCM诊断层。DCM负责解析UDS服务，PduR负责路由，CanTp负责把超过单帧长度的PDU拆分、发送、重组。CanTp对外的接口、配置项，比如N_PCI长度、帧类型、块大小、STmin，全都基于ISO 15765-2的帧格式。

这也意味着：即便你不用完整AUTOSAR栈，只是在单片机上自己写一个简易的诊断收发程序，也需要按同样的帧格式收发。因为ECU固件、诊断仪、测试工具之间能对话，靠的就是“每一种帧的数据字节布局完全一致”这个约定。格式哪怕错一个bit，轻则一帧校验失败，重则整个多帧传输被接收方直接中止。

1.3 四种帧是一个完整的“运输系统”

我习惯把这四种帧类比成快递运输：单帧（SF）就是小包裹，一个人直接扛走；首帧（FF）是大件包裹的运单，上面写着“总共有多少件”，顺便带上第一批货；流控帧（FC）是收件人回复调度中心的确认函，“一次送几件、每两件之间至少隔多少分钟”；连续帧（CF）就是按顺序赶来的一辆辆货车，每辆车身上都印着序号，方便收件人对齐顺序、发现丢件。

这里注意一个重点：多帧会话中，通信双方不是平等的。发送方（比如ECU回诊断响应时）负责按协议拆包和发送；接收方（一般是诊断仪）负责确认首帧、回流控帧、检查连续帧序号、重组数据。谁发起多帧、谁回流控，取决于当前这条PDU是请求还是响应、长度是否超过7字节。

把这段逻辑想清楚后，接下来的字节级拆解就好懂多了。下面我按每一帧的结构逐字节拆，包括高位、低位、长度、序号、流控参数，这些细节正是最容易看走眼的地方。

2. 四种帧的字节级拆解与编码规则

先把四种帧的PCI布局汇总成一张表，后面每一类再细讲：

2.1 单帧SF：一位PCI加最多7字节数据

单帧的PCI只占1字节，结构是高4位固定为0x0，低4位表示后续数据长度，取值范围0~7。所以一帧标准CAN帧里，单帧能装载的最大用户数据就是7字节。例如诊断仪发起的请求“10 03”（进入扩展诊断会话），实际CAN报文数据场是03 10 03：第一个03就是PCI，表示后面有3个数据字节，10 03才是UDS服务。

这里有个很容易误解的点：单帧PCI里的“长度”不包含PCI本身。如果低4位写0x03，后面只允许再跟3个字节；写0x07，后面跟7个字节。有的初学者会把整个8字节都当成数据，把CAN帧data[0]也当服务数据来解，结果解析出来的UDS服务号全是错的。

单帧是最安稳的一帧，不涉及流控，也不需要接收方确认。接收方读到一个0x0X开头的帧，直接取低4位长度，再把后面的数据交给上层解析即可。唯一要留意的是：如果低4位长度写0，表示这是一条没有数据内容的空PDU，正常诊断中很少见到，但协议栈要能容忍，不能崩。

2.2 首帧FF：总共多少数据，先交代清楚

当待发送数据超过7字节，发送方就不能用单帧了，必须先发一个首帧。首帧的PCI占2字节：第一个字节的高4位固定是0x1，低4位与第二个字节组合成一个12位的长度值，最大可以表示4095字节。也就是说，ISO 15765-2在标准CAN下最多支持一条诊断PDU按4095字节来拆。

因为PCI占了2字节，首帧能附带的数据只有6字节。它会在发出首帧的同时，把整条PDU的前6个字节一起带上，这样接收方不用等收齐所有连续帧才拿到第一个字节，效率会高一些。

举例：如果ECU要回一条20字节的响应，首帧第一个字节为0x10，第二个字节为0x14（0x10的高4位1表示FF，低4位1与0x14合并为0x014=20），后面的6个字节就是响应的前6字节。看到0x10开头的帧，接收方就知道“接下来会有一次多帧传输”，并且马上能算出总共还差多少字节。这个“总长度”是后续所有数据场里的用户数据字节数，不包含FF的两个PCI字节，也不包含后续每个CF的PCI字节。

2.3 流控帧FC：接收方把握传输节奏

首帧发出后，发送方不能自顾自地继续发连续帧，要等接收方回一个流控帧。流控帧的PCI固定3字节：第一个字节高4位是0x3，低4位是流控状态FS，0表示继续发送CTS，1表示等待WT，2表示溢出中止OVFLW；第二个字节是块大小BlockSize（BS）；第三个字节是最小间隔时间STmin。

为什么必须等流控？因为接收方可能正在处理别的事情，缓冲区也可能不够。比如ECU一边刷写一边回数据，缓冲区只剩几十字节，它就在流控帧里告诉诊断仪：“一次最多发这么多字节，每帧至少隔多少毫秒”。发送方照做，就不会把接收方的缓冲区冲爆。

值得说明的是，BS=0是一种特殊情况，表示不限定块大小，你把所有连续帧一口气发完，我照单全收。但这并不意味着可以毫不停顿地连发，STmin仍然生效。STmin通常填0x00~0x7F，对应0~127毫秒；0x80~0xF0区间是微秒级扩展编码，实际量产ECU用得少，绝大多数工具和ECU默认填毫秒值就够了。

2.4 连续帧CF：按序号接力，最后一段不用满7字节

接收方返回CTS之后，发送方开始发连续帧。每个连续帧的PCI占1字节，高4位固定是0x2，低4位是序号SN，取值范围0~15，循环使用。第一个连续帧的SN必须是0，也就是PCI为0x20；第二个是0x21；以此类推，走到0x2F之后下一个回到0x20。接收方会严格检查SN是否按预期递增，一旦发现跳号，就会判定这一条多帧PDU损坏。

连续帧每帧最多带7字节数据，比首帧多1字节，因为只有1字节PCI。如果PDU总长度不是7的倍数，那么最后一帧自然不满7字节，这是正常的。接收方在收满FF里声明的总长度后，就不再等后续帧了。很多初级开发者看到最后一帧不足7字节会怀疑是不是丢数据，实际上接收方要看的不是“每帧都满”，而是“总的到达字节数等于FF里申报的长度”。

SN还有一个隐藏用途：配合超时时间做丢帧检测。接收方收到CF后启动定时器，如果超过N_Cr还没等到下一帧，就认为发送方出了故障，可以停止等待或向上层报错。

3. 多帧传输的协商机制与关键参数计算

3.1 流控帧的三个参数分别管什么

多帧传输能不能稳定跑通，很大程度取决于流控帧里BS和STmin填的数值。BS决定“每发多少个连续帧后，发送方必须停下来等下一次流控”，STmin决定“连续帧之间的最小发送间隔”。两者不是相乘，是叠加约束。举例来说，BS=3、STmin=10ms，意味着连续发3个CF，帧与帧之间至少隔10ms，发完第3个后停下来等接收方回下一个FC。如果BS=0，整个传输过程中不再有分组门禁，只保留STmin的间隔限制。

这里面的“行为主体”容易搞混：STmin约束的是发送方每发完一帧后必须等待的最短时间，不是最大时间。发送方可以比STmin更慢，但绝不能更快。BS约束的是连续帧的分组边界，接收方在每收满BS个CF后才回一个FC。假如接收方一直不回FC，发送方会按N_Bs超时停止，而不是傻等。

我在项目里见过不少工程师把STmin理解成“接收方处理数据需要的时间”或者“接收方的响应时间”，其实都不准确。STmin本质上是给接收方留出逐帧处理的时间。接收方如果处理得快，就把STmin填小；处理得慢，就填大一点。同理，BS填小可以降低接收方每次突发处理的压力，但会增加额外的流控往返，总时间变长。

3.2 发送方和接收方各自需要维护的状态

做协议栈实现时，最好不要边发边想“下一步怎么办”，而是把多帧传输定义成一个状态机。发送方至少要有：空闲态、等待首帧后流控态、发送连续帧态、等待块流控态；接收方至少要有：空闲态、等待连续帧态、组装完整态。

整个链路是这样走的：

发送方发FF后，进入等待流控的时间窗口N_Bs。收到FC后检查FS：CTS就按BS和STmin发送CF；WAIT就继续等，但不能无限等，超过N_Bs或N_Cr要中止；OVFLW直接放弃整条传输。

接收方收到FF后，记录总长度，发回FC，然后等着接收CF。每收一个CF，检查SN是否连续，并把数据拼进缓冲区。当累计数据长度等于FF声明的总长度时，这条PDU重组完成，交给上层；如果SN跳号或者等待超时，接收方要么发OVFLW主动终止，要么直接丢弃。

这两套状态机看起来简单，但很多疑难杂症就出在状态没有正确复位：比如某次多帧传输被中止后，发送方还停留在“等待流控”状态，下一次新的FF来了它没反应，形成“ECU假死”的效果。排查这种问题，先看协议栈的状态机复位逻辑，往往比改参数更有效。

3.3 一次完整多帧传输的逐拍推演

我拿一个贴近日常的例子：读取VIN。诊断仪发“22 F1 90”，请求读取VIN标识，响应里除了服务号和DID之外，还有17字节的VIN数据，整条响应正好20字节。这条链路大概这样走：

1. 诊断仪发单帧请求：03 22 F1 90。PCI=03，后面3字节是UDS服务。
2. ECU回首帧：10 14 62 F1 90 AA BB CC。PCI两字节表示总长0x014=20，先带6字节，其中62 F1 90是正响应和DID，AA BB CC是VIN前3字节占位。
3. 诊断仪回流控帧：30 00 14。FS=0表示CTS，BS=0表示不限制块，STmin=20ms。
4. ECU发第一个连续帧：20 D1 D2 D3 D4 D5 D6 D7，SN=0，带7字节。
5. ECU发第二个连续帧：21 D8 D9 DA DB DC DD DE，SN=1，带最后7字节。
6. 诊断仪累计收到6+7+7=20字节，重组完成，交给UDS层解析，得到完整的“62 F1 90 + 17字节VIN”。

这个例子里，FF后等FC，FC后按20ms间隔发两个CF。BS=0所以省去了块间流控。如果BS改成1，那么每发一个CF都要等接收方再回一次FC，时间会明显变长，但接收方的缓冲压力也小，低速ECU更喜欢这种配置。

这类推演在排查“响应太慢”时非常有用：你可以在Trace里数一数一次多帧传输中出现了几次FC往返，每次等待了多久。如果发现BS设成了0x01，一次VIN读取可能要来回六七个报文，响应时间自然被拖慢。合理调大BS或者改成BS=0，响应时间立刻改善。

4. 实战拆包：把一段CAN报文还原成完整诊断响应

4.1 动手之前先确认三件事

在实际项目中，我们拿到的往往不是干净的协议数据，而是带各种干扰的CAN报文。所以我拿到一段Trace，不会急着逐帧解析，先确认三件事。

第一，确认寻址方式。如果CAN ID是传统的11位ID标准帧，PCI从数据场第一个字节开始；如果采用扩展寻址，数据场第一个字节是子地址，比如常见的0x7F，PCI就要从第二个字节看起。很多解析工具里如果把扩展地址定义成报文里的某个信号，解析时忘了偏移1字节，整段数据都会错位。

第二，确认ECU回的是物理寻址响应还是功能寻址响应。功能寻址（比如向0x7DF发请求）时，多个ECU都可能在同一个CAN ID上同时回单帧，这本身没问题；但多帧响应在功能寻址下极易产生流控帧冲突，所以绝大多数多帧响应都走物理寻址。

第三，确认当前CAN网络的帧类型。标准CAN数据场8字节，CAN FD可能更长。如果是CAN FD，SF/FF能装的数据量会大于经典CAN，但ISO 15765-2的PCI头部结构不变，只是“每帧能装多少数据”变了。

4.2 逐帧解析的完整操作

假设总线调试工具窗口里有这样一串报文，0x7E0是诊断仪请求ID，0x7E8是ECU响应ID：

• 0x7E0：03 22 F1 90
• 0x7E8：10 14 62 F1 90 AA BB CC
• 0x7E0：30 00 14
• 0x7E8：20 D1 D2 D3 D4 D5 D6 D7
• 0x7E8：21 D8 D9 DA DB DC DD DE

我解析的步骤是固定的。

先看0x7E0那帧。data[0]=0x03，高4位0x0，是单帧，低4位长度3，数据是22 F1 90。这是UDS的ReadDataByIdentifier请求，DID是0xF190。

再看0x7E8的首帧。data[0]=0x10，高4位0x1是FF，data[1]=0x14，于是总长度=0x014=20字节。数据从data[2]开始：62 F1 90 AA BB CC，共6字节。0x62是ReadDataByIdentifier的正响应，DID=0xF190，后面AA BB CC是VIN前3字节的占位。

然后诊断仪回0x30 00 14。data[0]=0x30，FS=0允许发，BS=0不分组，STmin=20ms。

继续看连续帧。第一帧data[0]=0x20，高4位0x2是CF，SN=0，后面D1~D7共7字节；第二帧data[0]=0x21，SN=1，后面D8~DE共7字节。VIN剩余14字节正好补齐。整条响应就是：62 F1 90 加上17字节VIN数据，总长20字节，和FF声明一致。

这样拆下来，你就能确认端到端的数据链路是通的，也能精确判断问题出在哪一段。

4.3 用工具核对和反向验证

手工拆包适合练手和排查，但平时联调我建议配合总线工具里的协议解码功能。大多数专业CAN调试工具都内置ISO 15765-2解码，你只需要把收发报文的CAN ID配置成诊断ID，工具会自动把FF/CF拼成完整数据。如果工具显示出来的多帧数据不完整，多半是寻址方式配置错了，或者CAN ID过滤范围不对。

反向验证也有一个实用技巧：如果工具解码结果和你手工拆的不一致，别急着怀疑工具。先把原始数据按上面的步骤自己拆一遍，数一下FF里声明的总长度是否等于收到的所有CF数据长度之和。很多时候工具解码失败，是因为FF的长度字段和实际发送长度对不上，接收端的协议栈不会装傻，直接把整条PDU丢了。

我还习惯在主流的总线分析工具里写一个小解析器，按CAN ID分类统计：每一条多帧传输里CF数量是否符合预期、SN是否连续、FC延时是否超过了N_Bs。写这个解析器时你会发现，你对四种帧格式的理解会被迫精确到一个bit，很多隐藏问题就是在写解析器的过程中暴露的。

5. 在AUTOSAR配置和实车联调中踩过的坑

5.1 连续帧SN“开头不对”和回绕问题

第一次做ECU多帧响应时，我按“习惯”把第一个连续帧的SN写成了1，结果诊断仪一直在那等下一帧，最后超时。查过标准才发现，FF后的第一个连续帧SN必须是0，也就是说data[0]=0x20而不是0x21。一些自研协议栈对SN的起始值并不在意，收到0x21开头也照收，但正规诊断仪和测试工具会严格校验，SN只要不在预期位置，整条多帧传输就被判定无效。

另一个容易踩的是SN回绕。当连续帧超过15个，SN会从0x2F回绕到0x20。接收方必须有“预期SN=（当前SN+1）&0x0F”这样的逻辑，不能简单用大于、小于判断。我就见过同事在纯C代码里用if(SN > lastSN)判断连续性，传输超过16帧后直接状态错乱。

排查SN问题有个很有效的办法：在测试工具里开故障注入，人为篡改下一个CF的SN，看接收方是否能立即识别并中止。如果接收方毫无反应，说明它的SN检查逻辑有洞。

5.2 BS、STmin配错引发响应超时

某项目里，ECU响应总在“读多字节DID”时超时。抓包发现：流控帧里的STmin=0x00，发送方几乎是背靠背发CF，而接收方缓冲区有限，后面几帧被CAN控制器直接丢弃，接收方等待N_Cr超时后中止传输，上层表现就是“诊断响应超时”。

这事的根子是STmin配置得太激进。有人可能觉得零延迟不是更快吗，但在高负载总线上，诊断仪连发多个CF时，ECU的中断处理、协议栈逐帧复制、上层解析未必能跟上。把STmin从0x00改成0x0A（10ms）后，这个毛病就消失了。同理，BS如果设得太小，比如0x01，每次发一个CF都要等一个FC，来回握手的时间会显著拖慢响应；设成0x00无限块时，又可能让某些低速接收方缓冲溢出。所以BS和STmin本质是一对trade-off，必须根据接收方的缓冲能力和总线负载去配，不存在一个万能值。

我现在的经验是：默认先配BS=0、STmin=0x0A~0x14（10~20ms）让链路跑通，如果总线上还有其他高优先级报文或接收缓冲较小，再适当加大STmin或减小BS。这个组合在绝大多数8字节标准CAN诊断场景里都很稳。

5.3 扩展寻址和功能寻址带来的“隐形偏移”

在部分车内网络上，诊断报文用扩展寻址，数据场第一个字节是子地址。有些ECU的CanTp配置里设了PCI偏移，但诊断仪侧的解析配置没有同步，于是工具在解析多帧响应时把所有字节都往左偏移了一位，整条数据全错。

这种问题在表面上和协议栈本身没有关系，排查时最容易走弯路。我的建议是先看数据场第一个字节是不是固定的扩展地址，如果是，说明要走扩展寻址解析，PCI一律从data[1]开始。流控帧也一样，扩展寻址下流控帧的数据场会多占一个字节，BS和STmin对应的字节位置要右移。

功能寻址则是另一个坑。诊断仪向0x7DF发功能寻址请求，多个ECU同时回单帧，各说各话还好；但如果有ECU需要回多帧响应，多个ECU同时发FF，诊断仪侧的流控帧根本无法确认发给谁。我遇到过功能寻址请求“读软件版本号”，几个ECU同时回多帧，总线直接被冲乱，最后改成物理寻址才消停。所以在项目里尽量让所有多帧响应走物理寻址。

5.4 我的自查清单和调试节奏

踩过这么多坑后，我总结了一份自查清单，每次多帧传输出问题就按顺序过一遍：

1. 先确认是不是数据长度超了7字节却误用了单帧格式。
2. 确认FF长度字段是否等于PDU总长度，不包含PCI本身。
3. 确认FC的FS值：0继续、1等待、2中止，别把0x32当成继续。
4. 确认第一个CF的SN是0x20，后续每个CF的SN连续递增。
5. 确认CF数量是否足够，最后一段不满7字节是正常现象。
6. 确认BS、STmin和接收方缓冲能力是否匹配，必要时抓Trace量FC间隔。
7. 确认寻址方式：标准寻址看data[0]，扩展寻址从data[1]开始。
8. 确认多帧会话是否长时间无响应，检查状态机是否复位、N_Bs和N_Cr是否被触发。

我调试时习惯用最小的场景先自测：故意发一条刚好8字节的PDU，再发一条刚好9字节的PDU，逼它走FF加一个CF的路径，看协议栈能不能拼完整。这种边界测试比直接上复杂的几十字节刷写流程更能快速暴露问题。

往后再遇到“ECU不回响应”或者“诊断仪收不到多帧数据”，先把这8条过一遍，大概率能在十分钟内定位到是格式问题、参数问题还是配置问题。这套方法帮我不止一次把疑难杂症变成了已知问题，也希望对你排查自己的项目有所帮助。

最后再补一句个人心得：多帧传输不怕数据大，就怕状态乱。只要时刻记得“首帧报总长、流控定节奏、连续帧按序号”，ISO 15765-2这套协议再怎么变，你都有底气去拆解它。