第一次自己动手往总线上灌多帧诊断请求的时候我犯了个特别典型的错误把 29 个字节的刷写数据直接拆成四条 CAN 帧发出去然后在电脑这端干等响应等了半天什么都没有。总线上抓下来的数据看着还挺像那么回事四条帧的数据加起来也确实是对的可 ECU 那边就是一声不吭。后来把抓包文件拉出来一帧一帧啃才发现首帧里的长度域写错了而且我压根没给对面留出发流控帧的机会——连发四条连续帧物理层都不带喘气的接收端的缓冲区早就被打穿了。那次之后我才老老实实去把 ISO15765 这套东西从头啃了一遍也才算明白 UDS 的 0x22、0x2E、0x31 这些服务为什么写在文档里那么清爽真正落地干活的时候却全卡在下面这一层。这篇笔记就专门讲 ISO15765也就是 UDS 跑在 CAN 上时那一层网络与传输的规矩。它要解决的事情其实特别朴素CAN 一帧就 8 个字节扣掉 PCI 之后能装的有效数据更少而 UDS 的请求和响应动不动就几十上百字节读取 VIN 要 20 字节读 DTC 快照可能要 200 多字节刷写的时候一个 block 几百字节起步。这么大的数据块怎么塞进 8 字节的格子里怎么让接收方知道哪一帧是开头、哪一帧是结尾、哪一帧丢了、哪一帧该重发全是 ISO15765 在管。搞嵌入式诊断、写上位机工具、做 HIL 测试台架、分析刷写失败现场的同学这一层绕不过去。我下面按帧怎么组、地址怎么给、时间怎么掐、错了怎么办这个顺序来讲中间夹着实测抓包和我自己写过的一个最小收发器尽量让你看完就能对着自己的工程改。1. 多帧请求发不出去问题往往不在UDS服务层很多人第一次碰多帧诊断脑子里只有 UDS 那一层服务号 0x22、DID 是什么、肯定响应是不是 0x62。这个思路在单帧场景下能跑通因为请求短、响应也短一帧装得下。可一旦数据超过 7 个字节链路上发生的事情就跟 UDS 没多大关系了全是传输层在做事。这四个帧类型构成全双工的数据管道。发送方有大数据要送先甩一个首帧FF告诉对方我这一包总共多少字节接收方收到首帧之后回一个流控帧FC告诉对方你可以开始发了每次发几帧两帧之间隔多久发送方按照流控帧的指示一帧一帧地发连续帧CF每帧带一个循环递增的序列号接收方靠序列号判断有没有丢帧、有没有重复。数据量小于等于 7 字节的时候走单帧SF压根不用握手一问一答最干脆。我在一个台架项目上见过更隐蔽的问题单帧请求发下去ECU 正常回肯定响应大伙都以为链路没问题了。结果换个 DID响应变成 20 字节上位机直接超时报错。排查了半天 UDS 服务最后发现是上位机工具根本没实现接收侧的多帧重组收到首帧之后不知道后面还有连续帧把首帧当成完整响应丢给上层解析UDS 层一看数据长度不对自然报错。这种单帧通、多帧不通的现象在现场太常见了八成以上的锅都在传输层。判断故障落在哪一层的土办法抓包看总线上有没有流控帧。如果请求方发了首帧响应方一个字节都没回问题在响应方没识别出首帧或者地址配错了如果响应方回了流控帧但请求方没有接着发连续帧问题在请求方的流控处理逻辑如果连续帧发出去了但响应方还在等那是序列号或者长度域对不上。还有一个容易忽略的点ISO15765 不只管 CAN 数据链路以上的拆包重组它还把用哪个 CAN ID 通信两帧之间至少间隔多久对方多久不回算超时这些事一并定死了。这也是为什么你在不同项目里看到的诊断 ID 大多是 0x7xx 打头超时参数大多是 1000 毫秒——不是巧合是标准给的那几个推荐值被人抄来抄去。2. N_PCI四个帧类型的位级拆解与手工组包每个诊断 CAN 帧的第一个字节都叫N_PCIProtocol Control Information高 4 位是帧类型低 4 位是这一类帧自己的参数。这个设计很省地方一字节就够表达这是什么帧 附加参数剩下的 7 个字节全给数据。先把这张表记住后面所有内容都是在填这张表。帧类型高4位低4位含义典型场景单帧 SF0x0SF_DL有效数据长度短请求、短响应首帧 FF0x1FF_DL 高4位长响应首包连续帧 CF0x2SN序列号长数据后续包流控帧 FC0x3FS流控状态接收方回给发送方2.1 单帧7字节天花板和CAN FD的转义机制经典 CAN 下单帧的有效负载最多 7 字节因为第一字节被 PCI 占了。这个 7 字节的限制直接影响了整个诊断协议的设计——所有能塞进 7 字节的请求都做成单帧塞不进去的才走多帧握手。像10 03进扩展会话、3E 00会话保持、11 01硬复位这些都是 2 字节单帧属于最省事的一类。组包逻辑很直白第一字节写0x0LL 就是后面有效数据的字节数剩下的位置用填充值补齐到 8 字节。填充值标准里建议用 0xCC 或者 0xAA具体用哪个看项目约定实测下来大部分 ECU 对填充值不敏感只要长度对就行。不过我在一个项目上遇到过对填充值挑剔的 ECU用 0x00 填充会返回否定响应换成 0xCC 就正常这种就属于厂家实现细节了抓包对比一下就能发现。def build_single_frame(payload: bytes, pad: int 0xCC) - bytes: 经典CAN单帧组包payload长度1~7 assert 1 len(payload) 7, 单帧最多7字节 frame bytes([len(payload)]) payload return frame bytes([pad]) * (8 - len(frame))CAN FD 把这个天花板抬高了。FD 一帧最多 64 字节如果还按老规矩用 4 位表示长度最多只能到 15明显不够用。所以标准里加了个转义当单帧有效数据超过 7 字节时第一字节低 4 位填 0实际长度放到第二字节。这样一来 FD 下的单帧能装到 62 字节绝大多数诊断请求都能一帧搞定直接把多帧握手的开销省掉了。要注意这是转义而不是扩展接收方看到第一字节低 4 位为 0 且还有第二字节时必须按 FD 的规则去读长度不能当成长度为 0 的空帧。我见过自己写解析器的同学在这里翻车收到00 3E 00 ...直接返回空数据其实人家是 62 字节的单帧。2.2 首帧12位长度域与32位转义的边界首帧要回答的核心问题是这一包总共多长。经典 CAN 下用 12 位表示也就是第一字节低 4 位当高 4 位、第二字节当低 8 位最大能表达 4095 字节。数据从第三字节开始放所以首帧本身携带 6 个字节的有效数据。为什么是 4095因为 4096 这个数量级已经覆盖了绝大多数诊断响应长度刷写场景虽然单个 block 可能上万字节但刷写协议通常会把大块拆成多个不超过 4K 的传输单元规避掉 12 位的限制。真要超过 4095 怎么办标准给了转义方案首帧长度域填 0紧接着的四个字节表示 32 位长度。这时候首帧只剩 2 个字节的有效数据了效率低得感人属于能用但不常见的路径。CAN FD 下情况反过来了因为单帧就能干到 62 字节超过 62 字节才需要走首帧而 FD 的首帧长度域有 32 位甚至更多的版本实际项目里 4095 这个坎基本不会碰到。场景首帧长度域写法首帧可带数据经典CAN≤4095字节12位两字节6字节经典CAN4095字节FF_DL0后接32位长度2字节CAN FD≤62字节通常用单帧搞定—CAN FD大包32位长度域视 DLC 而定判断长度域时有个细节要注意首帧里的长度是整包长度不是剩余长度。有些自己实现的发送端会写成首帧之后的剩余字节数接收方按整包长度去校验最后发现数据多了 6 个字节的垃圾解析出来的 VIN 后面挂着几个填充字符。这种 bug 特别隐蔽因为数据内容看着是对的。2.3 连续帧SN从1开始的强制约定意味着什么连续帧的低 4 位是序列号 SN取值 1 到 15然后回到 0继续循环。注意起点是 1 不是 0这是 ISO15765 里一个经常被记错的地方。为什么这么设计因为首帧之后紧跟着的第一帧就是 SN1用1 开始能让状态机少一个初始化分支逻辑更顺。回到 0 只是循环的自然结果不是起点。序列号的真正作用不是排序而是检测丢帧和重复帧。CAN 本身有 CRC 和重传机制正常情况下不会丢但流控帧里的 STmin 设置得太短、或者接收方软件处理不过来导致溢出就会出现某个连续帧没被接收方收进缓冲区的现象。接收方靠 SN 不连续立刻就能发现中间少了一帧然后中止本次接收、把缓冲区清干净。这个机制比等到整包收完再校验长度要快得多也安全得多——刷写场景里收到一段错位的数据去写 Flash后果很严重。# 连续帧 PCI 生成SN 从 1 开始循环 sn 1 def next_cf_pci(): global sn pci 0x20 | sn sn (sn 1) 0x0F # 15 - 0 return pci我在一份自己写的测试脚本里把起点写成了 0结果对着某款 ECU 一直过不去。抓包一看我的第一帧连续帧是20 ...ECU 回了否定响应。改回21 ...立刻正常。这种坑没法靠读 UDS 服务文档发现只能对着传输层规范抠。2.4 流控帧FS、BS、STmin三者如何决定吞吐流控帧是接收方说的话它的三个参数字节各有分工。第一字节低 4 位是 FSFlow Status取值 0 表示继续发送CTS1 表示等待WAIT2 表示溢出OVFLW其他值保留。第二字节是BSBlock Size表示我允许你连发多少帧之后必须停下来等我的下一个流控帧填 0 表示不限一口气发完。第三字节是STmin表示两帧连续帧之间的最小间隔。这三个参数组合出来的传输行为差异很大。BS8、STmin0 的意思是你一次最多连发 8 帧中间不用等发完这 8 帧停下来等我。BS0、STmin10 的意思是你随便发多少帧但每帧之间至少隔 10 毫秒。后者吞吐低但接收方压力小前者吞吐高但要求接收方缓冲区足够大。实际项目里常见的是 BS0 配 STmin0属于我全都要的激进配置一般用在 ECU 对 PC 发响应这种接收方很宽裕的场景反过来 PC 给 ECU 发长请求时ECU 回的流控帧往往会保守一些比如 BS8 配 STmin0因为 ECU 的接收缓冲区是按固定大小设计出来的。参数典型值含义影响FS00x30继续发送正常流程FS10x31等待发送方重置超时继续等FS20x32溢出中止本次传输BS0 / 8 / 0x10每个块的帧数影响握手频次STmin0 / 10 / 0xF3帧间最小间隔影响吞吐与接收压力要特别注意流控帧只在多帧接收时由接收方发出单帧不用。而且响应方向的流控帧是接收方比如 PC 工具回给发送方ECU的方向跟请求正好相反。很多工具抓包时看到30 00 00这种帧第一反应是谁发的请求其实就是自己在回流控。3. 寻址方式的选择11位ID、29位固定寻址与扩展寻址的实际差别ISO15765 定义了四种寻址方式名字听着抽象实际区别就一句话目标地址和源地址藏在哪。可以藏在 CAN ID 里可以藏在数据首字节里也可以混着来。3.1 普通寻址的ID映射规律普通寻址最简单一个 ECU 的物理请求 ID 对应一个物理响应 ID两者靠固定偏移绑定。11 位 ID 场景下的惯例是请求 0x7E0、响应 0x7E8偏移正好 8。功能寻址用 0x7DF 广播所有 ECU 都能收到。这套 ID 分配不是标准强制的只是行业里形成的默契但默契的好处很明显看到 0x7E0 就知道是发给第一个 ECU 的请求看到 0x7E8 就知道是它的回话不用查 DBC 也能猜个八九不离十。0x7E0 到 0x7E7 对应 8 个 ECU 的请求0x7E8 到 0x7EF 对应它们的响应0x7DF 是功能寻址的广播口。用途11位ID范围常见取值物理请求0x7E0–0x7E70x7E0物理响应0x7E8–0x7EF0x7E8功能请求0x7DF0x7DF29 位 ID 下有一套叫普通固定寻址的编码方式格式是0x18DAxxyy和0x18DBxxyy其中 DA 表示请求、DB 表示响应xx 是目标地址yy 是源地址。比如诊断仪地址 0xF1、ECU 地址 0x10请求就是0x18DA10F1响应是0x18DB10F1。这种编码把地址信息揉进了 ID好处是数据字节全给内容一帧能多装一个字节的有效数据坏处是 ID 长得不规律抓包时需要工具帮忙翻译成可读格式。3.2 扩展寻址省下的那一个ID扩展寻址的做法是把目标地址放在数据首字节也就是说每帧的第一个字节先写地址第二字节才是 PCI第三字节开始才是数据。这么一来单帧的有效数据就从 7 字节降到了 6 字节代价明确。为什么要这么干因为当你需要在一组 ID 上挂很多个 ECU或者需要在同一路 CAN 上区分不同网络节点的时候扩展寻址能省下大量 ID 资源——所有节点可以共用一个请求 ID靠首字节的地址来区分目标。这套做法在老车型的诊断里见得比较多新平台上基本被 29 位固定寻址取代了毕竟地址编码在 ID 里更干净也方便工具解析。如果你在抓包里看到某个帧的第一个字节是0xF1、第二个字节才是03 22 ...这种结构基本可以断定走的是扩展寻址。3.3 功能寻址为什么只能单帧功能寻址是用一个 ID 广播给所有 ECU谁匹配谁响应。这里有个必须记住的硬约束功能寻址只能发单帧不能发多帧。道理很直白。假如一帧首帧广播出去十个 ECU 同时收到都回一个流控帧总线上瞬间撞成一团就算不撞这十个 ECU 的响应也会同时涌上来物理层直接乱套。标准干脆把这条路封死功能寻址只允许单帧而且响应也要按各自物理 ID 分开发。带来的实际影响是像刷写时的擦除、进编程会话这些广播型操作请求必须压缩到 7 字节以内超过就得挨个用物理寻址点对点发。功能寻址还有一个坑某些 ECU 收到功能寻址请求后不回肯定响应只在不满足条件时回否定响应。这是标准允许的省流量做法别以为没响应就是没执行。4. 定时参数与错误恢复1000ms和N_WFTmax背后的设计传输层如果只定义帧格式两边速度对不上照样得崩所以 ISO15765 还定义了一整套定时器和错误恢复流程。这几个参数在配置工具里经常被忽视填个默认值就过但一旦现场出现偶发超时这类神出鬼没的问题基本都得从这儿翻。4.1 六个网络层定时器的分工标准里给发送方和接收方各定义了三个超时一共六个。名字都以N_开头看着头大其实可以按角色拆开理解As/Ar管单帧发送本身Bs/Br管流控帧Cs/Cr管连续帧。字母 s 代表发送方视角r 代表接收方视角。参数谁在等等什么典型值N_As发送方自己把一帧发到总线上1000 msN_Ar接收方自己把流控帧发出去1000 msN_Bs发送方等对方回的第一个流控帧1000 msN_Br接收方自己内部准备下一个流控帧内部N_Cs发送方准备发出下一个连续帧内部N_Cr接收方等对方下一个连续帧1000 ms1000 毫秒这个值不是拍脑袋定的。它得同时满足两个矛盾的需求一方面要足够长让 ECU 在忙的时候比如 Flash 擦除中能暂时不给流控帧而不被误判超时另一方面要足够短让故障能被快速发现避免诊断仪傻等半分钟。1 秒是一个折中值实际项目里有的会放大到 2 秒甚至 5 秒特别是刷写流程中的擦除阶段。我在一个台架上就吃过这个亏。某个 ECU 在做 Flash 擦除时从收到首帧到发出流控帧中间隔了将近 1.5 秒诊断仪配的是默认 1 秒超时擦除阶段必挂。换了几版固件都没用最后把 N_Bs 调到 3 秒问题消失。这种问题光看现象会以为是 ECU 死了其实人家只是慢。4.2 STmin的单位陷阱STmin 这个参数的单位有两套迷惑性极强。取值0x00 到 0x7F 时单位是毫秒所以0x0A就是 10 毫秒最大能到 127 毫秒。取值0xF1 到 0xF9 时单位变成 100 微秒0xF1是 100 微秒0xF9是 900 微秒。中间的 0x80 到 0xF0 和 0xFA 以上全是保留值。为什么搞两套单位因为毫秒档最高精度就是 1 毫秒但有些高速 CAN 的帧间隔需求在微秒级1 毫秒太粗了会严重拖慢吞吐。加了微秒档之后接收方可以用900 微秒这种细粒度的节奏控制发送速度又不至于把间隔设成 0 导致接收缓冲区被打爆。STmin 取值含义实际间隔0x00不限制由发送实现决定0x0A10 毫秒10 ms0x7F127 毫秒127 ms0x80–0xF0保留不应使用0xF1100 微秒0.1 ms0xF9900 微秒0.9 ms0xFA–0xFF保留不应使用发送方的义务是实际间隔不小于 STmin也就是说接收方要求 10 毫秒发送方实际隔了 12 毫秒、15 毫秒都没问题快于 10 毫秒就是违规。反过来接收方不能抱怨你怎么隔了 15 毫秒那是允许的。我在自己写的工具里最开始直接用time.sleep(stmin/1000)结果因为调度精度问题偶尔会短个几百微秒对着严格的 ECU 就报错。后来改成 sleep 之后再补一个短忙等才稳下来。4.3 超时与溢出之后的现场清理超时处理最容易写错的地方不是发现了超时而是发现超时之后怎么收场。标准要求双方在超时后都回到空闲状态清空接收缓冲等待下一次新传输同时把这次传输标记为失败上报给上层。问题在于如果只有一方清了、另一方没清就会出现状态错位发送方已经在等新的首帧了接收方还在等原来那包的连续帧接下来所有报文全对不上。另一种情况是接收方主动拒绝。当接收方发现数据长度超过自己的缓冲区上限它会在流控帧里填 FS2溢出然后整个传输作废。这个动作在刷写场景里不算罕见尤其是某些工具为了提升速度故意把 block 设得很大超过了 ECU 侧的上限。收到 FS2 之后发送方不该重试而应该把 block 拆小重新发起——重试同样的长度只会再收一次溢出。还有N_WFTmax这个参数用来限制接收方连续回 WAIT 帧的次数。收到 WAIT 之后发送方重置超时计时器继续等但如果接收方一直说等一下发送方不能无限期等下去超过设定的 WAIT 次数就判失败。这个参数填 0 表示不限制实践中大多数实现会填个 5 到 10既能容忍 ECU 短暂忙碌又不会真的卡死。5. 一次29字节VIN响应的抓包复盘光讲规则记不住还是得看真实的时序。下面这一段是读 VIN 的完整过程请求很短响应 20 字节正好触发首帧加两个连续帧的最小完整握手。这个例子我一直拿来给新人讲因为它把四种帧全用上了而且时序关系看得很清楚。# 请求物理寻址 0x7E0单帧4字节有效数据 7E0 03 22 F1 90 AA AA AA AA # 响应首帧0x7E8总长 20 字节 0x014携带 6 字节 7E8 10 14 62 F1 90 4D 59 54 # 接收方回流量控制CTSBS0 不限STmin0 7E0 30 00 00 AA AA AA AA AA # 连续帧 1SN17字节 7E8 21 45 53 54 56 49 4E 31 # 连续帧 2SN27字节 7E8 22 32 33 34 35 36 37 38把数据段拼起来首帧给62 F1 90 4D 59 54两个连续帧各给 7 字节一共 677 20 字节跟首帧里声明的 0x014 严丝合缝。去掉62 F1 90这三个字节的肯定响应头剩下 17 个字节正好是 VIN 的字符数。有意思的是时序里的停顿。首帧和流控帧之间、流控帧和第一个连续帧之间总线上其实有几毫秒的空隙这是软件处理的开销。这零点几毫秒的停顿不影响任何东西因为标准规定的超时是 1000 毫秒级别差着三个数量级。但如果这个停顿超过 1 秒那八成就是超时了。上面我特意用了 BS0、STmin0 这种不限速配置因为接收方是 PC 工具处理能力绰绰有余。反过来看另一个真实场景某 ECU 给 PC 回了30 08 0A意思是连发 8 帧每帧间隔 10 毫秒。这种配置说明 ECU 侧的接收缓冲比较保守每 8 帧就要停下来等一次流控同时帧间隔也不能太快。做上位机的时候要是把这个当成可选参数忽略掉一口气把几十帧全发出去ECU 那边铁定溢出然后回个 FS2 把整个传输干掉。判断谁是瓶颈的小技巧连续帧之间的实际间隔如果明显大于 STmin说明发送方软件在忙别的如果刚好等于 STmin那就是正常按规矩在发。前一种情况在压力测试里很常见因为发送线程被高优先级任务抢占了。6. 用几十行Python写一个最小ISO-TP收发器工具再好用原理还是得自己实现一遍才踏实。我当年就是靠手写一个收发器才算把序列号、长度域、流控这几件事彻底弄明白。下面这段代码只做最核心的收发没有重传、没有并发、没有 FD 支持但足够让你在一台带 CAN 接口的机器上对着 ECU 跑通读 VIN。6.1 接收侧状态机接收侧的核心就是收到首帧进入忙态一直收连续帧直到凑满长度。状态机很浅一两个变量就够但校验必须做全。class IsoTpReceiver: def __init__(self): self.buf bytearray() self.remain 0 self.sn 0 self.busy False def feed(self, frame: bytes): 输入一个8字节CAN帧完整时返回 payload否则返回 None if len(frame) 8: return None pci frame[0] 4 if pci 0x0: # 单帧 dl frame[0] 0x0F if dl 0 or dl 7: raise ValueError(单帧长度非法) return bytes(frame[1:1 dl]) if pci 0x1: # 首帧 total ((frame[0] 0x0F) 8) | frame[1] if total 7: raise ValueError(首帧长度应大于7否则该用单帧) self.buf bytearray(frame[2:8]) self.remain total - 6 self.sn 1 self.busy True return None if pci 0x2 and self.busy: # 连续帧 got frame[0] 0x0F if got ! self.sn: self.reset() raise ValueError(f序列号错位期望{self.sn}收到{got}) self.sn (self.sn 1) 0x0F take min(self.remain, 7) self.buf frame[1:1 take] self.remain - take if self.remain 0: out bytes(self.buf) self.reset() return out return None return None def reset(self): self.buf.clear() self.remain 0 self.busy False self.sn 0这段代码有几个刻意的设计。单帧那里加了dl 7的判断是因为我在现场见过长度域写 8 的错误实现标准经典 CAN 下单帧最大就是 7写 8 属于非法。首帧那里判断total 7也是个实用的检查能发 7 字节以内的数据本来就是单帧的活用首帧发说明发送端逻辑有问题早点报错比后面莫名奇妙好。6.2 发送侧的流程控制发送侧比接收侧多一个握手环节首帧发出去之后必须等流控帧拿到 BS 和 STmin 之后才能开闸。等流控帧这段时间要设超时不能让线程死等。import time def send_multiframe(send_raw, wait_fc, payload: bytes, pad0xCC): send_raw(frame) : 把一帧发到总线上 wait_fc(timeout) : 阻塞等待流控帧返回 (fs, bs, stmin)超时返回 None total len(payload) if total 7: send_raw(bytes([total]) payload bytes([pad]) * (7 - total)) return # 首帧12位长度域带6字节数据 ff bytes([0x10 | (total 8), total 0xFF]) payload[:6] send_raw(ff bytes([pad]) * (8 - len(ff))) fc wait_fc(timeout1.0) if fc is None: raise TimeoutError(等流控帧超时) fs, bs, stmin fc if fs 2: raise RuntimeError(接收方溢出需要拆小数据块) if fs 1: raise RuntimeError(接收方要求等待此处需实现重试) # STmin 换算成秒 if stmin 0x7F: gap stmin / 1000.0 elif 0xF1 stmin 0xF9: gap (stmin - 0xF0) / 10000.0 else: gap 0.0 idx 6 sn 1 cnt_in_block 0 while idx total: chunk payload[idx:idx 7] frame bytes([0x20 | sn]) chunk bytes([pad]) * (7 - len(chunk)) send_raw(frame) idx len(chunk) sn (sn 1) 0x0F cnt_in_block 1 if gap 0: time.sleep(gap) if bs and cnt_in_block bs and idx total: fc wait_fc(timeout1.0) if fc is None: raise TimeoutError(块间隔等流控超时) _, bs, stmin fc cnt_in_block 0这里有一处特别容易写错块的计数是在发完 BS 帧之后清零重新数的而且只在还有后续数据时才等下一个流控帧。如果最后一块刚好用完 BS 的额度但数据也发完了就不该再等流控——多等一次会白白撞一个超时。6.3 实测验证把这两段接上真实的 CAN 接口对着台架 ECU 跑一遍基本能稳定读到 VIN。我自己验证的时候会额外做两件事一是故意改坏一帧的 SN看接收侧能不能按预期抛异常二是把 STmin 强行改小一半看 ECU 会不会通过流控帧把速度压回来。这两项测过之后才算对这个协议栈有底。如果不想从零写现成的开源实现也不少常见的有 Python 的can-isotp库以及 Linux 内核里自带的 CAN ISO-TP 支持配合python-can能把收发简化到几行代码。用现成库的好处是定时器和错误恢复都实现了坏处是出了问题你不知道该往哪儿看。我的建议是先自己写一遍再换库两相对照理解会深很多。# 用现成库的写法对比感受一下抽象层级 import isotp import can bus can.interface.Bus(interfacesocketcan, channelcan0, bitrate500000) addr isotp.Address(isotp.AddressingMode.Normal_11bits, txid0x7E0, rxid0x7E8) stack isotp.CanStack(busbus, addressaddr, params{stmin: 0, blocksize: 8}) stack.send(b\x03\x22\xF1\x90) resp stack.recv() print(resp.hex( ))7. 实际项目里踩过的几个坑最后把几个印象深刻的问题记一下都是文档里不会写、但真遇上了能耗掉一整天的那种。长度域和填充长度不一致。有些实现会按实际数据长度去截断 CAN 帧比如一帧本来 8 字节它只发 6 字节有效加 2 字节填充结果 DLC 也设成 8 但填充值没写总线上就是脏数据。接收方按整包长度累加最后多出几个字节解析出来的字符串后面挂着乱码。查这个问题只能靠抓包逐帧比对长度。流控帧的方向搞反。PC 发请求、ECU 回响应这个方向谁都清楚但连续帧传输中的流控帧是接收方发给发送方的方向跟数据流相反。我在一个自制脚本里把流控帧当成了要接收的东西结果发出首帧之后一直在等别人给我流控实际上应该是我主动回给 ECU。这种方向性错误在换寻址方式的时候特别容易犯因为 ID 全变了。29 位 ID 下的掩码配置。用 29 位固定寻址时CAN 控制器的接收过滤器要按 ID 的高位做屏蔽比如只匹配0x18DA前缀。掩码写错就会出现某些 ECU 收得到、某些收不到的诡异现象——因为 ID 的低位里编码了目标地址和源地址掩码范围一宽就把别的节点也放进来了。CAN FD 下 DLC 与数据长度不匹配。FD 的 DLC 编码不是线性的12/16/20/24/32/48/64 这些档位之间有空档写 20 进去实际会变成 24 字节。如果按 20 去组包、按 24 去解析中间的填充值就混进数据里了。这个坑在做 FD 诊断移植的时候几乎必踩一次。多帧传输中途被别的报文打断。诊断走的是普通 CAN 报文没有优先级保证。如果传输过程中有高优先级的周期性报文插进来连续帧的实际间隔就可能超过 STmin 的要求这个允许但如果插得太多导致接收方等不来下一帧就会撞 N_Cr 超时。这种情况下调大 N_Cr 比调小 STmin 更有效。响应长度刚好卡在 7 字节边界。数据 7 字节走单帧8 字节就得走首帧加一个连续帧握手开销瞬间翻倍。有些 ECU 为了省事会把响应里加一个无意义的填充字节凑到 8 字节然后走多帧——看着浪费其实是为了让上位机走统一的处理路径。这种实现细节只能靠大量抓包总结没有文档可查。我个人在实际操作中的体会是ISO15765 这一层难的不是概念而是细节的确定性。格式、时序、状态机都能背下来但真到总线上跑决定成败的往往是填充值填什么超时设多长BS 给多少这些看起来无关紧要的参数。每次接新 ECU我都会先用抓包工具跑一遍单帧、多帧、超时三个最小用例把对方的习惯摸清楚再往下做比直接上大流程要省时间得多。 
长河君 · 2026/11/3 6:52:47 · 阅读 1.2k ISO15765多帧传输与流控实战：UDS诊断在CAN上的落地细节
第一次自己动手往总线上灌多帧诊断请求的时候我犯了个特别典型的错误把 29 个字节的刷写数据直接拆成四条 CAN 帧发出去然后在电脑这端干等响应等了半天什么都没有。总线上抓下来的数据看着还挺像那么回事四条帧的数据加起来也确实是对的可 ECU 那边就是一声不吭。后来把抓包文件拉出来一帧一帧啃才发现首帧里的长度域写错了而且我压根没给对面留出发流控帧的机会——连发四条连续帧物理层都不带喘气的接收端的缓冲区早就被打穿了。那次之后我才老老实实去把 ISO15765 这套东西从头啃了一遍也才算明白 UDS 的 0x22、0x2E、0x31 这些服务为什么写在文档里那么清爽真正落地干活的时候却全卡在下面这一层。这篇笔记就专门讲 ISO15765也就是 UDS 跑在 CAN 上时那一层网络与传输的规矩。它要解决的事情其实特别朴素CAN 一帧就 8 个字节扣掉 PCI 之后能装的有效数据更少而 UDS 的请求和响应动不动就几十上百字节读取 VIN 要 20 字节读 DTC 快照可能要 200 多字节刷写的时候一个 block 几百字节起步。这么大的数据块怎么塞进 8 字节的格子里怎么让接收方知道哪一帧是开头、哪一帧是结尾、哪一帧丢了、哪一帧该重发全是 ISO15765 在管。搞嵌入式诊断、写上位机工具、做 HIL 测试台架、分析刷写失败现场的同学这一层绕不过去。我下面按帧怎么组、地址怎么给、时间怎么掐、错了怎么办这个顺序来讲中间夹着实测抓包和我自己写过的一个最小收发器尽量让你看完就能对着自己的工程改。1. 多帧请求发不出去问题往往不在UDS服务层很多人第一次碰多帧诊断脑子里只有 UDS 那一层服务号 0x22、DID 是什么、肯定响应是不是 0x62。这个思路在单帧场景下能跑通因为请求短、响应也短一帧装得下。可一旦数据超过 7 个字节链路上发生的事情就跟 UDS 没多大关系了全是传输层在做事。这四个帧类型构成全双工的数据管道。发送方有大数据要送先甩一个首帧FF告诉对方我这一包总共多少字节接收方收到首帧之后回一个流控帧FC告诉对方你可以开始发了每次发几帧两帧之间隔多久发送方按照流控帧的指示一帧一帧地发连续帧CF每帧带一个循环递增的序列号接收方靠序列号判断有没有丢帧、有没有重复。数据量小于等于 7 字节的时候走单帧SF压根不用握手一问一答最干脆。我在一个台架项目上见过更隐蔽的问题单帧请求发下去ECU 正常回肯定响应大伙都以为链路没问题了。结果换个 DID响应变成 20 字节上位机直接超时报错。排查了半天 UDS 服务最后发现是上位机工具根本没实现接收侧的多帧重组收到首帧之后不知道后面还有连续帧把首帧当成完整响应丢给上层解析UDS 层一看数据长度不对自然报错。这种单帧通、多帧不通的现象在现场太常见了八成以上的锅都在传输层。判断故障落在哪一层的土办法抓包看总线上有没有流控帧。如果请求方发了首帧响应方一个字节都没回问题在响应方没识别出首帧或者地址配错了如果响应方回了流控帧但请求方没有接着发连续帧问题在请求方的流控处理逻辑如果连续帧发出去了但响应方还在等那是序列号或者长度域对不上。还有一个容易忽略的点ISO15765 不只管 CAN 数据链路以上的拆包重组它还把用哪个 CAN ID 通信两帧之间至少间隔多久对方多久不回算超时这些事一并定死了。这也是为什么你在不同项目里看到的诊断 ID 大多是 0x7xx 打头超时参数大多是 1000 毫秒——不是巧合是标准给的那几个推荐值被人抄来抄去。2. N_PCI四个帧类型的位级拆解与手工组包每个诊断 CAN 帧的第一个字节都叫N_PCIProtocol Control Information高 4 位是帧类型低 4 位是这一类帧自己的参数。这个设计很省地方一字节就够表达这是什么帧 附加参数剩下的 7 个字节全给数据。先把这张表记住后面所有内容都是在填这张表。帧类型高4位低4位含义典型场景单帧 SF0x0SF_DL有效数据长度短请求、短响应首帧 FF0x1FF_DL 高4位长响应首包连续帧 CF0x2SN序列号长数据后续包流控帧 FC0x3FS流控状态接收方回给发送方2.1 单帧7字节天花板和CAN FD的转义机制经典 CAN 下单帧的有效负载最多 7 字节因为第一字节被 PCI 占了。这个 7 字节的限制直接影响了整个诊断协议的设计——所有能塞进 7 字节的请求都做成单帧塞不进去的才走多帧握手。像10 03进扩展会话、3E 00会话保持、11 01硬复位这些都是 2 字节单帧属于最省事的一类。组包逻辑很直白第一字节写0x0LL 就是后面有效数据的字节数剩下的位置用填充值补齐到 8 字节。填充值标准里建议用 0xCC 或者 0xAA具体用哪个看项目约定实测下来大部分 ECU 对填充值不敏感只要长度对就行。不过我在一个项目上遇到过对填充值挑剔的 ECU用 0x00 填充会返回否定响应换成 0xCC 就正常这种就属于厂家实现细节了抓包对比一下就能发现。def build_single_frame(payload: bytes, pad: int 0xCC) - bytes: 经典CAN单帧组包payload长度1~7 assert 1 len(payload) 7, 单帧最多7字节 frame bytes([len(payload)]) payload return frame bytes([pad]) * (8 - len(frame))CAN FD 把这个天花板抬高了。FD 一帧最多 64 字节如果还按老规矩用 4 位表示长度最多只能到 15明显不够用。所以标准里加了个转义当单帧有效数据超过 7 字节时第一字节低 4 位填 0实际长度放到第二字节。这样一来 FD 下的单帧能装到 62 字节绝大多数诊断请求都能一帧搞定直接把多帧握手的开销省掉了。要注意这是转义而不是扩展接收方看到第一字节低 4 位为 0 且还有第二字节时必须按 FD 的规则去读长度不能当成长度为 0 的空帧。我见过自己写解析器的同学在这里翻车收到00 3E 00 ...直接返回空数据其实人家是 62 字节的单帧。2.2 首帧12位长度域与32位转义的边界首帧要回答的核心问题是这一包总共多长。经典 CAN 下用 12 位表示也就是第一字节低 4 位当高 4 位、第二字节当低 8 位最大能表达 4095 字节。数据从第三字节开始放所以首帧本身携带 6 个字节的有效数据。为什么是 4095因为 4096 这个数量级已经覆盖了绝大多数诊断响应长度刷写场景虽然单个 block 可能上万字节但刷写协议通常会把大块拆成多个不超过 4K 的传输单元规避掉 12 位的限制。真要超过 4095 怎么办标准给了转义方案首帧长度域填 0紧接着的四个字节表示 32 位长度。这时候首帧只剩 2 个字节的有效数据了效率低得感人属于能用但不常见的路径。CAN FD 下情况反过来了因为单帧就能干到 62 字节超过 62 字节才需要走首帧而 FD 的首帧长度域有 32 位甚至更多的版本实际项目里 4095 这个坎基本不会碰到。场景首帧长度域写法首帧可带数据经典CAN≤4095字节12位两字节6字节经典CAN4095字节FF_DL0后接32位长度2字节CAN FD≤62字节通常用单帧搞定—CAN FD大包32位长度域视 DLC 而定判断长度域时有个细节要注意首帧里的长度是整包长度不是剩余长度。有些自己实现的发送端会写成首帧之后的剩余字节数接收方按整包长度去校验最后发现数据多了 6 个字节的垃圾解析出来的 VIN 后面挂着几个填充字符。这种 bug 特别隐蔽因为数据内容看着是对的。2.3 连续帧SN从1开始的强制约定意味着什么连续帧的低 4 位是序列号 SN取值 1 到 15然后回到 0继续循环。注意起点是 1 不是 0这是 ISO15765 里一个经常被记错的地方。为什么这么设计因为首帧之后紧跟着的第一帧就是 SN1用1 开始能让状态机少一个初始化分支逻辑更顺。回到 0 只是循环的自然结果不是起点。序列号的真正作用不是排序而是检测丢帧和重复帧。CAN 本身有 CRC 和重传机制正常情况下不会丢但流控帧里的 STmin 设置得太短、或者接收方软件处理不过来导致溢出就会出现某个连续帧没被接收方收进缓冲区的现象。接收方靠 SN 不连续立刻就能发现中间少了一帧然后中止本次接收、把缓冲区清干净。这个机制比等到整包收完再校验长度要快得多也安全得多——刷写场景里收到一段错位的数据去写 Flash后果很严重。# 连续帧 PCI 生成SN 从 1 开始循环 sn 1 def next_cf_pci(): global sn pci 0x20 | sn sn (sn 1) 0x0F # 15 - 0 return pci我在一份自己写的测试脚本里把起点写成了 0结果对着某款 ECU 一直过不去。抓包一看我的第一帧连续帧是20 ...ECU 回了否定响应。改回21 ...立刻正常。这种坑没法靠读 UDS 服务文档发现只能对着传输层规范抠。2.4 流控帧FS、BS、STmin三者如何决定吞吐流控帧是接收方说的话它的三个参数字节各有分工。第一字节低 4 位是 FSFlow Status取值 0 表示继续发送CTS1 表示等待WAIT2 表示溢出OVFLW其他值保留。第二字节是BSBlock Size表示我允许你连发多少帧之后必须停下来等我的下一个流控帧填 0 表示不限一口气发完。第三字节是STmin表示两帧连续帧之间的最小间隔。这三个参数组合出来的传输行为差异很大。BS8、STmin0 的意思是你一次最多连发 8 帧中间不用等发完这 8 帧停下来等我。BS0、STmin10 的意思是你随便发多少帧但每帧之间至少隔 10 毫秒。后者吞吐低但接收方压力小前者吞吐高但要求接收方缓冲区足够大。实际项目里常见的是 BS0 配 STmin0属于我全都要的激进配置一般用在 ECU 对 PC 发响应这种接收方很宽裕的场景反过来 PC 给 ECU 发长请求时ECU 回的流控帧往往会保守一些比如 BS8 配 STmin0因为 ECU 的接收缓冲区是按固定大小设计出来的。参数典型值含义影响FS00x30继续发送正常流程FS10x31等待发送方重置超时继续等FS20x32溢出中止本次传输BS0 / 8 / 0x10每个块的帧数影响握手频次STmin0 / 10 / 0xF3帧间最小间隔影响吞吐与接收压力要特别注意流控帧只在多帧接收时由接收方发出单帧不用。而且响应方向的流控帧是接收方比如 PC 工具回给发送方ECU的方向跟请求正好相反。很多工具抓包时看到30 00 00这种帧第一反应是谁发的请求其实就是自己在回流控。3. 寻址方式的选择11位ID、29位固定寻址与扩展寻址的实际差别ISO15765 定义了四种寻址方式名字听着抽象实际区别就一句话目标地址和源地址藏在哪。可以藏在 CAN ID 里可以藏在数据首字节里也可以混着来。3.1 普通寻址的ID映射规律普通寻址最简单一个 ECU 的物理请求 ID 对应一个物理响应 ID两者靠固定偏移绑定。11 位 ID 场景下的惯例是请求 0x7E0、响应 0x7E8偏移正好 8。功能寻址用 0x7DF 广播所有 ECU 都能收到。这套 ID 分配不是标准强制的只是行业里形成的默契但默契的好处很明显看到 0x7E0 就知道是发给第一个 ECU 的请求看到 0x7E8 就知道是它的回话不用查 DBC 也能猜个八九不离十。0x7E0 到 0x7E7 对应 8 个 ECU 的请求0x7E8 到 0x7EF 对应它们的响应0x7DF 是功能寻址的广播口。用途11位ID范围常见取值物理请求0x7E0–0x7E70x7E0物理响应0x7E8–0x7EF0x7E8功能请求0x7DF0x7DF29 位 ID 下有一套叫普通固定寻址的编码方式格式是0x18DAxxyy和0x18DBxxyy其中 DA 表示请求、DB 表示响应xx 是目标地址yy 是源地址。比如诊断仪地址 0xF1、ECU 地址 0x10请求就是0x18DA10F1响应是0x18DB10F1。这种编码把地址信息揉进了 ID好处是数据字节全给内容一帧能多装一个字节的有效数据坏处是 ID 长得不规律抓包时需要工具帮忙翻译成可读格式。3.2 扩展寻址省下的那一个ID扩展寻址的做法是把目标地址放在数据首字节也就是说每帧的第一个字节先写地址第二字节才是 PCI第三字节开始才是数据。这么一来单帧的有效数据就从 7 字节降到了 6 字节代价明确。为什么要这么干因为当你需要在一组 ID 上挂很多个 ECU或者需要在同一路 CAN 上区分不同网络节点的时候扩展寻址能省下大量 ID 资源——所有节点可以共用一个请求 ID靠首字节的地址来区分目标。这套做法在老车型的诊断里见得比较多新平台上基本被 29 位固定寻址取代了毕竟地址编码在 ID 里更干净也方便工具解析。如果你在抓包里看到某个帧的第一个字节是0xF1、第二个字节才是03 22 ...这种结构基本可以断定走的是扩展寻址。3.3 功能寻址为什么只能单帧功能寻址是用一个 ID 广播给所有 ECU谁匹配谁响应。这里有个必须记住的硬约束功能寻址只能发单帧不能发多帧。道理很直白。假如一帧首帧广播出去十个 ECU 同时收到都回一个流控帧总线上瞬间撞成一团就算不撞这十个 ECU 的响应也会同时涌上来物理层直接乱套。标准干脆把这条路封死功能寻址只允许单帧而且响应也要按各自物理 ID 分开发。带来的实际影响是像刷写时的擦除、进编程会话这些广播型操作请求必须压缩到 7 字节以内超过就得挨个用物理寻址点对点发。功能寻址还有一个坑某些 ECU 收到功能寻址请求后不回肯定响应只在不满足条件时回否定响应。这是标准允许的省流量做法别以为没响应就是没执行。4. 定时参数与错误恢复1000ms和N_WFTmax背后的设计传输层如果只定义帧格式两边速度对不上照样得崩所以 ISO15765 还定义了一整套定时器和错误恢复流程。这几个参数在配置工具里经常被忽视填个默认值就过但一旦现场出现偶发超时这类神出鬼没的问题基本都得从这儿翻。4.1 六个网络层定时器的分工标准里给发送方和接收方各定义了三个超时一共六个。名字都以N_开头看着头大其实可以按角色拆开理解As/Ar管单帧发送本身Bs/Br管流控帧Cs/Cr管连续帧。字母 s 代表发送方视角r 代表接收方视角。参数谁在等等什么典型值N_As发送方自己把一帧发到总线上1000 msN_Ar接收方自己把流控帧发出去1000 msN_Bs发送方等对方回的第一个流控帧1000 msN_Br接收方自己内部准备下一个流控帧内部N_Cs发送方准备发出下一个连续帧内部N_Cr接收方等对方下一个连续帧1000 ms1000 毫秒这个值不是拍脑袋定的。它得同时满足两个矛盾的需求一方面要足够长让 ECU 在忙的时候比如 Flash 擦除中能暂时不给流控帧而不被误判超时另一方面要足够短让故障能被快速发现避免诊断仪傻等半分钟。1 秒是一个折中值实际项目里有的会放大到 2 秒甚至 5 秒特别是刷写流程中的擦除阶段。我在一个台架上就吃过这个亏。某个 ECU 在做 Flash 擦除时从收到首帧到发出流控帧中间隔了将近 1.5 秒诊断仪配的是默认 1 秒超时擦除阶段必挂。换了几版固件都没用最后把 N_Bs 调到 3 秒问题消失。这种问题光看现象会以为是 ECU 死了其实人家只是慢。4.2 STmin的单位陷阱STmin 这个参数的单位有两套迷惑性极强。取值0x00 到 0x7F 时单位是毫秒所以0x0A就是 10 毫秒最大能到 127 毫秒。取值0xF1 到 0xF9 时单位变成 100 微秒0xF1是 100 微秒0xF9是 900 微秒。中间的 0x80 到 0xF0 和 0xFA 以上全是保留值。为什么搞两套单位因为毫秒档最高精度就是 1 毫秒但有些高速 CAN 的帧间隔需求在微秒级1 毫秒太粗了会严重拖慢吞吐。加了微秒档之后接收方可以用900 微秒这种细粒度的节奏控制发送速度又不至于把间隔设成 0 导致接收缓冲区被打爆。STmin 取值含义实际间隔0x00不限制由发送实现决定0x0A10 毫秒10 ms0x7F127 毫秒127 ms0x80–0xF0保留不应使用0xF1100 微秒0.1 ms0xF9900 微秒0.9 ms0xFA–0xFF保留不应使用发送方的义务是实际间隔不小于 STmin也就是说接收方要求 10 毫秒发送方实际隔了 12 毫秒、15 毫秒都没问题快于 10 毫秒就是违规。反过来接收方不能抱怨你怎么隔了 15 毫秒那是允许的。我在自己写的工具里最开始直接用time.sleep(stmin/1000)结果因为调度精度问题偶尔会短个几百微秒对着严格的 ECU 就报错。后来改成 sleep 之后再补一个短忙等才稳下来。4.3 超时与溢出之后的现场清理超时处理最容易写错的地方不是发现了超时而是发现超时之后怎么收场。标准要求双方在超时后都回到空闲状态清空接收缓冲等待下一次新传输同时把这次传输标记为失败上报给上层。问题在于如果只有一方清了、另一方没清就会出现状态错位发送方已经在等新的首帧了接收方还在等原来那包的连续帧接下来所有报文全对不上。另一种情况是接收方主动拒绝。当接收方发现数据长度超过自己的缓冲区上限它会在流控帧里填 FS2溢出然后整个传输作废。这个动作在刷写场景里不算罕见尤其是某些工具为了提升速度故意把 block 设得很大超过了 ECU 侧的上限。收到 FS2 之后发送方不该重试而应该把 block 拆小重新发起——重试同样的长度只会再收一次溢出。还有N_WFTmax这个参数用来限制接收方连续回 WAIT 帧的次数。收到 WAIT 之后发送方重置超时计时器继续等但如果接收方一直说等一下发送方不能无限期等下去超过设定的 WAIT 次数就判失败。这个参数填 0 表示不限制实践中大多数实现会填个 5 到 10既能容忍 ECU 短暂忙碌又不会真的卡死。5. 一次29字节VIN响应的抓包复盘光讲规则记不住还是得看真实的时序。下面这一段是读 VIN 的完整过程请求很短响应 20 字节正好触发首帧加两个连续帧的最小完整握手。这个例子我一直拿来给新人讲因为它把四种帧全用上了而且时序关系看得很清楚。# 请求物理寻址 0x7E0单帧4字节有效数据 7E0 03 22 F1 90 AA AA AA AA # 响应首帧0x7E8总长 20 字节 0x014携带 6 字节 7E8 10 14 62 F1 90 4D 59 54 # 接收方回流量控制CTSBS0 不限STmin0 7E0 30 00 00 AA AA AA AA AA # 连续帧 1SN17字节 7E8 21 45 53 54 56 49 4E 31 # 连续帧 2SN27字节 7E8 22 32 33 34 35 36 37 38把数据段拼起来首帧给62 F1 90 4D 59 54两个连续帧各给 7 字节一共 677 20 字节跟首帧里声明的 0x014 严丝合缝。去掉62 F1 90这三个字节的肯定响应头剩下 17 个字节正好是 VIN 的字符数。有意思的是时序里的停顿。首帧和流控帧之间、流控帧和第一个连续帧之间总线上其实有几毫秒的空隙这是软件处理的开销。这零点几毫秒的停顿不影响任何东西因为标准规定的超时是 1000 毫秒级别差着三个数量级。但如果这个停顿超过 1 秒那八成就是超时了。上面我特意用了 BS0、STmin0 这种不限速配置因为接收方是 PC 工具处理能力绰绰有余。反过来看另一个真实场景某 ECU 给 PC 回了30 08 0A意思是连发 8 帧每帧间隔 10 毫秒。这种配置说明 ECU 侧的接收缓冲比较保守每 8 帧就要停下来等一次流控同时帧间隔也不能太快。做上位机的时候要是把这个当成可选参数忽略掉一口气把几十帧全发出去ECU 那边铁定溢出然后回个 FS2 把整个传输干掉。判断谁是瓶颈的小技巧连续帧之间的实际间隔如果明显大于 STmin说明发送方软件在忙别的如果刚好等于 STmin那就是正常按规矩在发。前一种情况在压力测试里很常见因为发送线程被高优先级任务抢占了。6. 用几十行Python写一个最小ISO-TP收发器工具再好用原理还是得自己实现一遍才踏实。我当年就是靠手写一个收发器才算把序列号、长度域、流控这几件事彻底弄明白。下面这段代码只做最核心的收发没有重传、没有并发、没有 FD 支持但足够让你在一台带 CAN 接口的机器上对着 ECU 跑通读 VIN。6.1 接收侧状态机接收侧的核心就是收到首帧进入忙态一直收连续帧直到凑满长度。状态机很浅一两个变量就够但校验必须做全。class IsoTpReceiver: def __init__(self): self.buf bytearray() self.remain 0 self.sn 0 self.busy False def feed(self, frame: bytes): 输入一个8字节CAN帧完整时返回 payload否则返回 None if len(frame) 8: return None pci frame[0] 4 if pci 0x0: # 单帧 dl frame[0] 0x0F if dl 0 or dl 7: raise ValueError(单帧长度非法) return bytes(frame[1:1 dl]) if pci 0x1: # 首帧 total ((frame[0] 0x0F) 8) | frame[1] if total 7: raise ValueError(首帧长度应大于7否则该用单帧) self.buf bytearray(frame[2:8]) self.remain total - 6 self.sn 1 self.busy True return None if pci 0x2 and self.busy: # 连续帧 got frame[0] 0x0F if got ! self.sn: self.reset() raise ValueError(f序列号错位期望{self.sn}收到{got}) self.sn (self.sn 1) 0x0F take min(self.remain, 7) self.buf frame[1:1 take] self.remain - take if self.remain 0: out bytes(self.buf) self.reset() return out return None return None def reset(self): self.buf.clear() self.remain 0 self.busy False self.sn 0这段代码有几个刻意的设计。单帧那里加了dl 7的判断是因为我在现场见过长度域写 8 的错误实现标准经典 CAN 下单帧最大就是 7写 8 属于非法。首帧那里判断total 7也是个实用的检查能发 7 字节以内的数据本来就是单帧的活用首帧发说明发送端逻辑有问题早点报错比后面莫名奇妙好。6.2 发送侧的流程控制发送侧比接收侧多一个握手环节首帧发出去之后必须等流控帧拿到 BS 和 STmin 之后才能开闸。等流控帧这段时间要设超时不能让线程死等。import time def send_multiframe(send_raw, wait_fc, payload: bytes, pad0xCC): send_raw(frame) : 把一帧发到总线上 wait_fc(timeout) : 阻塞等待流控帧返回 (fs, bs, stmin)超时返回 None total len(payload) if total 7: send_raw(bytes([total]) payload bytes([pad]) * (7 - total)) return # 首帧12位长度域带6字节数据 ff bytes([0x10 | (total 8), total 0xFF]) payload[:6] send_raw(ff bytes([pad]) * (8 - len(ff))) fc wait_fc(timeout1.0) if fc is None: raise TimeoutError(等流控帧超时) fs, bs, stmin fc if fs 2: raise RuntimeError(接收方溢出需要拆小数据块) if fs 1: raise RuntimeError(接收方要求等待此处需实现重试) # STmin 换算成秒 if stmin 0x7F: gap stmin / 1000.0 elif 0xF1 stmin 0xF9: gap (stmin - 0xF0) / 10000.0 else: gap 0.0 idx 6 sn 1 cnt_in_block 0 while idx total: chunk payload[idx:idx 7] frame bytes([0x20 | sn]) chunk bytes([pad]) * (7 - len(chunk)) send_raw(frame) idx len(chunk) sn (sn 1) 0x0F cnt_in_block 1 if gap 0: time.sleep(gap) if bs and cnt_in_block bs and idx total: fc wait_fc(timeout1.0) if fc is None: raise TimeoutError(块间隔等流控超时) _, bs, stmin fc cnt_in_block 0这里有一处特别容易写错块的计数是在发完 BS 帧之后清零重新数的而且只在还有后续数据时才等下一个流控帧。如果最后一块刚好用完 BS 的额度但数据也发完了就不该再等流控——多等一次会白白撞一个超时。6.3 实测验证把这两段接上真实的 CAN 接口对着台架 ECU 跑一遍基本能稳定读到 VIN。我自己验证的时候会额外做两件事一是故意改坏一帧的 SN看接收侧能不能按预期抛异常二是把 STmin 强行改小一半看 ECU 会不会通过流控帧把速度压回来。这两项测过之后才算对这个协议栈有底。如果不想从零写现成的开源实现也不少常见的有 Python 的can-isotp库以及 Linux 内核里自带的 CAN ISO-TP 支持配合python-can能把收发简化到几行代码。用现成库的好处是定时器和错误恢复都实现了坏处是出了问题你不知道该往哪儿看。我的建议是先自己写一遍再换库两相对照理解会深很多。# 用现成库的写法对比感受一下抽象层级 import isotp import can bus can.interface.Bus(interfacesocketcan, channelcan0, bitrate500000) addr isotp.Address(isotp.AddressingMode.Normal_11bits, txid0x7E0, rxid0x7E8) stack isotp.CanStack(busbus, addressaddr, params{stmin: 0, blocksize: 8}) stack.send(b\x03\x22\xF1\x90) resp stack.recv() print(resp.hex( ))7. 实际项目里踩过的几个坑最后把几个印象深刻的问题记一下都是文档里不会写、但真遇上了能耗掉一整天的那种。长度域和填充长度不一致。有些实现会按实际数据长度去截断 CAN 帧比如一帧本来 8 字节它只发 6 字节有效加 2 字节填充结果 DLC 也设成 8 但填充值没写总线上就是脏数据。接收方按整包长度累加最后多出几个字节解析出来的字符串后面挂着乱码。查这个问题只能靠抓包逐帧比对长度。流控帧的方向搞反。PC 发请求、ECU 回响应这个方向谁都清楚但连续帧传输中的流控帧是接收方发给发送方的方向跟数据流相反。我在一个自制脚本里把流控帧当成了要接收的东西结果发出首帧之后一直在等别人给我流控实际上应该是我主动回给 ECU。这种方向性错误在换寻址方式的时候特别容易犯因为 ID 全变了。29 位 ID 下的掩码配置。用 29 位固定寻址时CAN 控制器的接收过滤器要按 ID 的高位做屏蔽比如只匹配0x18DA前缀。掩码写错就会出现某些 ECU 收得到、某些收不到的诡异现象——因为 ID 的低位里编码了目标地址和源地址掩码范围一宽就把别的节点也放进来了。CAN FD 下 DLC 与数据长度不匹配。FD 的 DLC 编码不是线性的12/16/20/24/32/48/64 这些档位之间有空档写 20 进去实际会变成 24 字节。如果按 20 去组包、按 24 去解析中间的填充值就混进数据里了。这个坑在做 FD 诊断移植的时候几乎必踩一次。多帧传输中途被别的报文打断。诊断走的是普通 CAN 报文没有优先级保证。如果传输过程中有高优先级的周期性报文插进来连续帧的实际间隔就可能超过 STmin 的要求这个允许但如果插得太多导致接收方等不来下一帧就会撞 N_Cr 超时。这种情况下调大 N_Cr 比调小 STmin 更有效。响应长度刚好卡在 7 字节边界。数据 7 字节走单帧8 字节就得走首帧加一个连续帧握手开销瞬间翻倍。有些 ECU 为了省事会把响应里加一个无意义的填充字节凑到 8 字节然后走多帧——看着浪费其实是为了让上位机走统一的处理路径。这种实现细节只能靠大量抓包总结没有文档可查。我个人在实际操作中的体会是ISO15765 这一层难的不是概念而是细节的确定性。格式、时序、状态机都能背下来但真到总线上跑决定成败的往往是填充值填什么超时设多长BS 给多少这些看起来无关紧要的参数。每次接新 ECU我都会先用抓包工具跑一遍单帧、多帧、超时三个最小用例把对方的习惯摸清楚再往下做比直接上大流程要省时间得多。