1. 先从整车通信的分层关系说起CAN 是腿UDS 是规矩1.1 一次诊断请求从测试仪到 ECU 的完整旅程前阵子帮一个售后诊断工具的团队排查问题现象很奇怪测试仪通过车载 OBD 口连上一辆新能源车发 UDS 诊断协议里的 10 03 想切扩展会话ECU 却始终没反应。抓 CAN 通信波形物理层完全正常0x7E0 上的请求帧也能在总线上看到可 0x7E8 的应答就是等不回来。最后定位到 MCU 的验收滤波配置上——接收邮箱把本应该放行的诊断应答帧给过滤掉了。这个案例特别典型它把车载软件栈里最容易让新人懵掉的两层同时拉了出来底层是 CAN 通信上层是 UDS 诊断协议。很多人做 CAN 收发跑得很顺一到 UDS 就不知道怎么搭也有不少人把 ISO 14229 文档背得滚瓜烂熟但遇到总线波形异常、验收滤波丢帧、多帧重组超时这类底层的活照样无从下手。所以这篇文章我想把这么多年做车载通信和诊断开发沉淀下来的东西系统整理一遍从物理层波形判读到接收滤波 acccode 与 accmask 的配置逻辑再到 UDS 服务寻址和 ISO 15765-2 多帧状态机最后用三个真实联调案例收尾。先建立一个最关键的认知一辆车上的电子系统从上到下是应用功能 — 诊断协议 — 传输层 — CAN 通信 — 物理总线这么叠起来的。CAN 只负责把一帧数据可靠地送到总线上它不管这帧数据是转速信号还是诊断请求UDS 只负责规定请求什么、怎么应答、什么时候算错它也不关心数据走的是 CAN 还是以太网。打个比方CAN 是腿和路UDS 是交通规则。腿好不好决定了你走路会不会摔跤交通规则决定了你该往哪走、该用什么手势打招呼。两者互相独立但又必须配合。具体到一个实实在在的例子比如测试仪要读 ECU 里的 VIN 码请求是 22 F1 90ReadDataByIdentifierDID 为 F190。这个请求从测试仪软件发出来要先经过 UDS 应用层组包得到 3 个字节的载荷然后传输层判定这 3 个字节能塞进一帧 CAN 报文于是封成一个 Single FramePCI 为 03接着 CAN 控制器把这个数据帧以 0x7E0 这个仲裁 ID 发上总线ECU 端的 CAN 控制器收到后先做验收滤波ID 匹配的才放进接收邮箱ECU 的传输层把载荷提取出来还原成 22 F1 90最后这 3 个字节交给 UDS 分发模块找到 0x22 对应的处理函数去存储区读出 VIN按 62 F1 90 加 17 字节 VIN 数据的格式组应答。应答一共 20 个字节塞不进一帧 CAN于是传输层自动拆成 First Frame、Consecutive Frame 多帧发送中间还要等测试仪的 Flow Control。你看请求走一遍应用层打包 — 传输层分帧 — CAN 控制器发送响应再倒着走一遍。整个过程里CAN 层完全不知道自己在传什么UDS 层也完全不关心波特率和采样点。这就是分层设计的意义。1.2 分层思维在工程排障里的价值为什么要反复强调这个因为实际排障时第一件事不是看代码而是先判断问题到底出在哪一层。这个判断错了方向就全错了。故障现象大概率所在层首选排查工具总线电平异常、波形畸形、偶发 Bus Off物理层示波器报文发不出去、收不到、验收滤波丢帧数据链路层CANoe/PCAN 报文记录、寄存器检查多帧重组超时、丢帧、CF 序号错乱传输层 TP协议栈日志、CANoe 统计窗口能收到报文但返回 NRC、行为不符合预期应用层 UDS诊断脚本、诊断规范文档我见过太多工程师在应用层代码里找了一整天问题结果发现是物理层线束没接好也见过有人在示波器上盯了半天波形结果发现是验收滤波根本没把报文放进来。先把层次定位准排障效率能翻一倍。2. CAN 工程开发绕不开的三个硬指标终端电阻、波特率、帧格式2.1 终端电阻上电之前先量电阻做 CAN 通信开发台架搭起来第一步不是写代码而是确认总线物理连接是健康的。高速 CANISO 11898-2要求在总线物理两端各接一个 120Ω 终端电阻目的很简单吸收信号到达线端时的反射避免波形振铃误判电平。判断方式很简单在系统不上电的情况下用万用表量 CANH 和 CANL 之间的电阻测得大约 60Ω两个终端电阻都在位正常。测得大约 120Ω总线只有一端接了终端电阻缺一个。测得低于 50Ω终端电阻过多或者线束哪里搭在一起了。这个 60Ω 的读数来自两个 120Ω 电阻并联几乎是判断总线段落是否健康的最快手段。实车 OBD 口上CAN_H 是 6 号脚CAN_L 是 14 号脚插头怼上去量一下就知道这辆车的动力 CAN 物理连接是否完整。还有一点容易忽略分支线Stub长度。CAN 总线是线性拓扑每个节点应该尽量挂在主干上分支越短越好。500kbps 时分支长度一般建议控制在 0.3 米以内。有些工装图省事用一根 1 米多的飞线把 ECU 板子接到总线汇流排上波形边缘会明显振铃严重时直接通不过一致性测试。后面波形部分我会放一个真实案例。2.2 帧格式与 ID 规划仲裁和 ACK 是两个隐藏排障点CAN 报文帧结构相信大家都不陌生帧起始 SOF、仲裁段、控制段、数据段、CRC 段、ACK 段、EOF。其中有两个地方新人经常忽略但排障时非常有用。第一个是仲裁机制。CAN 总线上的节点发送报文时ID 值越小优先级越高。多个节点同时抢总线时显性位逻辑 0会覆盖隐性位逻辑 1所以 ID 小的报文在仲裁段占优势。这就是为什么整车网络里动力相关的关键报文比如扭矩、转速往往分配很小的 ID而诊断这类低频应用报文 ID 集中在 0x7E0 附近——它们优先级低但也足够用了。第二个是 ACK 槽。CAN 协议规定总线上任何一个节点只要正确收到一帧报文无论这帧报文是不是发给它的都会在 ACK 槽位置回一个显性位。如果发送方在 ACK 槽没有检测到显性电平它会认为自己发送失败并重发错误计数器也会增加。这个特性在排障里特别有用如果你在 CANoe 里看到某条报文持续重发或者示波器上该帧的 ACK 槽是隐性电平说明这条总线上除了发送节点外没有其他节点在正常接收。常见原因对端 ECU 没上电、CAN_H/CAN_L 接反、波特率不匹配导致接收端 CRC 校验老是失败。查到这里问题范围就缩小了很多。诊断常用的标准帧 ID 分配很简单测试仪发请求用 0x7E0 到 0x7E7物理寻址功能寻址统一用 0x7DFECU 应答用 0x7E8 到 0x7EF。如果企业用的是 29 位扩展帧寻址方式会按主机厂的规范另做定义但原理一致。在项目里拿到网络规范表第一件事就是把 ID 段、报文周期、信号定义整理成 DBC 或者 Excel后面所有联调和测试都依赖这份东西。2.3 波特率与采样点两个参数为什么总是一起出问题波特率不一致是最基础的配置错误两台设备波特率对不上总线上会看到大量错误帧谁都发不出去数据。但比波特率更隐蔽的是采样点不一致。CAN 控制器采样一个位不是在位时间中间采而是在位时间的某个百分比位置采一次。这个位置叫采样点Sample Point由位时序寄存器决定同步段 传播段/相位缓冲段 1然后采样点然后相位缓冲段 2。业内常见的做法是把采样点放在 75% 到 85% 之间。算一下比较直观假设 MCU 外设时钟 16MHz目标波特率 500kbps一个位时间是 2us。如果预分频后 TQ 为 125ns那一个位时间就是 16 个 TQ。想要 75% 采样点可以这么分配同步段 1 个 TQ相位缓冲段 1 和传播段合计 11 个 TQ相位缓冲段 2 留 4 个 TQ这样采样点位置在 (1 11) / 16 75%。如果总线上挂着不同厂家、不同芯片的多个 ECU各自采样点差异太大短距离没问题线束一长、负载一高就可能偶发 CRC 错误。所以我一直建议项目早期就把波特率和采样点定死写进网络规范所有节点按同一个配置来。联调时遇到间歇性丢帧先别急着怀疑软件逻辑对比一下各节点的采样点配置。3. CANH/CANL 波形判读一眼看出总线状态好坏3.1 测量方法与一组健康波形的样子判断 CAN 通信好坏的最直接手段是示波器看波形。很多人觉得看波形是硬件工程师的活其实做软件和测试的要是不懂波形判读遇到物理层问题会非常被动。测量时最好用差分探头直接把探头两端夹在 CANH 和 CANL 上看的就是差分信号。没有差分探头也可以用两个普通探头分别测 CANH、CANL 对地用示波器的 A-B 数学通道做差分但这样引入的共模噪声会大一些精度不如差分探头。触发建议设在下降沿上因为总线空闲时 CANH 是 2.5VSOF 是显性位CANH 会从 2.5V 往下掉到 3.5V这里注意显性位是逻辑 0但电平方向上 CANH 是往上跳到 3.5VCANL 往下掉到 1.5V所以用 CANH 的上升沿或者 CANL 的下降沿触发都可以。健康波形有三个特征。第一总线空闲时 CANH 和 CANL 都稳定在 2.5V 附近差分电压约为 0V。第二显性位期间CANH 应到 3.5V 左右CANL 应到 1.5V 左右差分电压约 2V。第三位与位之间的边沿干净没有明显过冲、振铃和台阶。时间轴上的判读也很重要。500kbps 时每个位是 2us你在波形上量一个位的时间如果是 4us说明实际波特率只有 250kbps双方没对上。我习惯把示波器时间轴调到每格 10us 到 20us先看整帧的位序列和 ACK 槽再放大到单 bit 看边沿质量两步基本能定位大部分物理层问题。3.2 常见波形异常对照表异常现象可能原因处理方向显性边沿过冲超过 5V出现振铃终端电阻缺失或分支线过长补齐两端 120Ω 终端、缩短分支显性电平不足差分电压不到 2V负载过重、CANH/CANL 有短路或漏电断电量 CANH/CANL 间及对地电阻隐性电平回不到 2.5V总线对电源或对地存在异常偏置静态量各路电压检查收发器周边电路位边缘出现台阶或抖动多节点驱动冲突、电磁干扰CANoe 查错误帧产生节点检查屏蔽和接地一帧报文里 ACK 槽始终是隐性总线上除发送方外无节点在正常接收查对端 ECU 供电、波特率、CAN_H/L 是否接反这里提一个很实用的经验波形异常和功能异常不一定同时出现。总线轻微振铃时CAN 控制器靠位时序的重同步能力还能勉强正确解码表面上报文收发正常但错误计数器一直在悄悄增长。积累到一定程度节点就会进入 Bus Off 状态停止收发。所以波形看着还行不代表没问题要结合 CANoe 里的 Error Frame 计数和收发器的错误寄存器综合判断。3.3 一个真实波形案例飞线引发的振铃有次在实验台架上做网关联调发现某一路 CAN 通信时好时坏CANoe 里错误帧每秒能有几十上百个。示波器一挂上去波形很难看显性跳变的上升沿过冲到了 5.5V 以上回落后还有一串振铃幅度接近 1V已经越过隐性/显性的判定阈值控制器就会出现误判。查了一圈问题出在一个 ECU 开发板接总线的线路上。那块板子没有 DB9 接口测试人员用一根将近 1 米的普通跳线焊了个端子直接怼到总线汇流排上。分支过长加上线没有双绞反射信号在总线上来回弹于是出现振铃。处理方式就是三件事把飞线换成双绞线长度压到 20 厘米以内同时在 ECU 开发板附近临时补一个 120Ω 终端电阻因为原总线这一段本身就缺终端。改完之后再抓波形振铃基本消失错误帧归零。这件事给我的教训是CAN 物理层的问题90% 出在终端电阻、分支长度、线缆类型这三个地方排查时按这个顺序来不要一上来就怀疑代码。4. 验收滤波 acccode 与 accmask别让无关报文打扰你的 MCU4.1 过滤原理门卫怎么决定放行哪一帧多数 MCU 的 CAN 控制器都带验收滤波功能目的是让无关报文不进入接收邮箱避免 CPU 被中断风暴打满。这里有两个寄存器accCode验收码和 accMask验收掩码名字在不同厂商的芯片里叫法略有差异但在 STM32 的 bxCAN 里对应 Filter ID 和 Mask在 NXP 的 FlexCAN 里对应 RXIMR 和 Filter 配置。过滤的判断逻辑用一句话概括掩码位为 1 的位必须匹配掩码位为 0 的位不关心。举个例子MCU 只想接收诊断应答帧 0x7E8标准帧 11 位 ID 全要匹配。那 accCode 就设成 0x7E8accMask 设成 0x7FF意思是 11 个 ID 位全部必须和验收码一致一帧 0x7E9 都进不来。如果希望接收 0x7E8 到 0x7EF 这 8 个 ID也就是八个 ECU 的应答帧都收那把 accMask 改成 0x7F8让低 3 位不参与匹配。0x7E8 到 0x7EF 的低 3 位正好覆盖 000 到 111这 8 个 ID 全都能进来。这里必须提醒一个容易搞反的点不同芯片的掩码位含义有可能相反。老的 SJA1000 控制器里AMR 的位是 1 表示忽略该位而 STM32 bxCAN 和 FlexCAN 的 RXIMR 是位为 1 表示必须匹配。如果你从老代码里搬了一套配置到新平台没注意这个差异滤波器行为会完全相反。我在项目里见过一位同事把 FlexCAN 的掩码设成 0x7FF结果原来想只收 0x7E8实际变成了除了 0x7E8 之外全收总线上一堆无关报文把他的空调面板刷得卡死。4.2 配置实例以 FlexCAN 和 bxCAN 为例以 NXP S32K 系列 FlexCAN 为例启用单个邮箱接收诊断应答帧大致配置思路如下/* 假设使用 MB0验收码为 0x7E8掩码为 0x7FF */ CAN0-RXIMR[0] 0x7FF; /* 所有 ID 位都必须匹配 */ CAN0-MB[0].ID 0x7E8; /* 本邮箱只接收 0x7E8 */ CAN0-MB[0].WORD0 0; /* 数据清空 */ CAN0-MB[0].CS CAN_CS_CODE(0b1010) | CAN_CS_IDE(0) | CAN_CS_DLC(8);注意一点FlexCAN 的接收邮箱需要把 CODE 置为接收空状态常见是 0b1010并且使能对应的中断或轮询标志。配置完滤波器后建议先发几帧不同 ID 的报文验证一下确认想收的能进来、不想收的进不来再继续往下开发。STM32 bxCAN 的配置更直观一点它把滤波分成标识符列表模式和掩码模式。掩码模式下CAN_FxR1 存的是期望的 IDCAN_FxR2 存的是掩码1 表示必须匹配。/* 只接收 0x7E8掩码模式 */ CAN_FilterInitStructure.CAN_FilterIdHigh (0x7E8 5) 8; /* 高字节 */ CAN_FilterInitStructure.CAN_FilterIdLow (0x7E8 5) 0xFF; /* 低字节 */ CAN_FilterInitStructure.CAN_FilterMaskIdHigh 0xFFE0; CAN_FilterInitStructure.CAN_FilterMaskIdLow 0x0000; CAN_FilterInitStructure.CAN_FilterMode CAN_FilterMode_IdMask; CAN_FilterInitStructure.CAN_FilterScale CAN_FilterScale_32bit;初看这段代码有点绕核心就是把 11 位 ID 左移 5 位放进 16 位的寄存器布局里掩码 0xFFE0 等价于 11 位全匹配。实际项目里我建议不要死记寄存器位布局直接从厂家 SDK 的抽象接口配尤其是用 CubeMX、MCUXpresso Config Tools 这类图形化工具把类型选成 Mask 模式填入 ID 和 Mask它能帮你算好寄存器值还不会写错高低字节。验收滤波还有个工程上的平衡问题过滤太严漏报文过滤太松CPU 被无关报文频繁打断。特别是诊断刷写场景0x7DF 功能寻址帧和 0x7E8 等 8 路应答同时存在我一般会开两个邮箱一个专门收 0x7E8 到 0x7EF另一个在刷写时临时收 0x7DF 或者广播报文刷完再关掉。这样既保证诊断通路稳定又不让无关帧轰炸主核。5. UDS 诊断协议开发从服务定义到寻址时序5.1 三类会话与服务的访问控制矩阵UDS 协议ISO 14229规定了很多诊断服务但不是所有服务在所有时刻都能用。ECU 上电后默认进入默认会话Default Session0x01通过 10 03 可以切到扩展会话Extended Session通过 10 02 可以切到编程会话Programming Session。这三个会话的权限是逐步放开的会话会话号典型用途常见可用服务默认会话0x01上电后自动进入只读类操作22 读数据、3E 保活、19 读故障码扩展会话0x03维保、标定、写入类操作2E 写数据、31 例程控制、28 通信控制编程会话0x02Bootloader 刷写27 安全访问、34/36/37 下载流程很多 ECU 会做访问控制矩阵比如某个 DID 只在扩展会话可读某个例程只在编程会话可启动。一旦请求不符合当前会话ECU 就回 NRC。常见的有 0x7FserviceNotSupportedInActiveSession服务在当前会话不可用和 0x7EsubFunctionNotSupportedInActiveSession子功能在当前会话不可用。做上层开发时这个矩阵是必须和主机厂对齐的。我见过一个项目测试仪在默认会话里发 31 01 02 03 想启动某个例程ECU 回 7F 31 7F。开发小哥第一反应是是不是这个例程没实现然后把应用层代码翻了个底朝天。最后翻规范才发现这个例程本身没问题但它只能在扩展会话里启动测试仪根本没先发 10 03。所以看到 NRC第一步永远是查会话状态第二步查当前安全等级第三步才是查参数范围。5.2 物理寻址与功能寻址功能寻址的响应要低调UDS 寻址分两种。物理寻址是一对一测试仪用 0x7E0 这个 ID 给特定 ECU 发请求这个 ECU 用 0x7E8 应答。功能寻址是一对多测试仪用 0x7DF 这个广播 ID 发请求总线上所有 ECU 都会收到并处理。这两种寻址方式的差异在响应策略上体现得最明显。ISO 14229 规定功能寻址请求通常不要求 ECU 发正响应因为如果总线上挂了 20 个 ECU20 个 ECU 同时应答报文 ID 相同直接总线冲突把网络打成一锅粥。所以在实际工程里功能寻址一般只用于两类场景一是唤醒类请求比如 3E 80 保活让所有 ECU 维持会话二是某些特殊服务需要全车广播比如 28 01 03 关闭所有非诊断报文。物理寻址就不用担心这个问题每个 ECU 的回 ID 是独立的0x7E8 给第一个 ECU0x7E9 给第二个以此类推。主机厂在定义网络规范时会把物理寻址 ID 段和功能寻址 ID 段都划清楚开发前一定先确认自己负责的 ECU 用的是哪一段。还有一点标准帧的寻址范围总共就 0x7E0 到 0x7EF 十几个 ID一个总线上挂的诊断节点一多就不够用。这种情况下主机厂会改用 29 位扩展帧寻址或者干脆走车载以太网 DoIP。原理还是这一套物理请求、功能请求、正响应、负响应只是载体变了。5.3 定时参数P2、P2* 和 S3 是怎么影响稳定性的诊断通信里有几个定时参数直接决定联调手感。P2Server_max 是 ECU 从收到请求到开始发响应的最长时间标准默认是 50ms。如果 ECU 应用层处理很快比如读个 RAM 里的计数器瞬时就能回但遇到 EEPROM 写入、DTC 快照清理这类慢操作50ms 根本不够。这时候 ECU 应该先回一帧 NRC 0x78requestCorrectlyReceived-ResponsePending告诉测试仪我收到了还在处理别急着超时等真正有了结果再回最终响应。这个后续的最终响应要在 P2*Server_max默认 5000ms内发出来。S3Server 是会话超时时间默认也是 5000ms。ECU 在扩展会话里如果 5 秒内没有收到任何诊断请求就会自动退回默认会话。这也是为什么测试工具在长时间标定操作时需要周期性地发 3E 80 保活帧把会话续住。实际联调时最常见的超时问题有两类。一类是执行慢操作时 ECU 没有先回 0x78导致测试仪等满 50ms 就报超时另一类相反ECU 回了 0x78但后续正响应超过 5 秒才发出来测试仪直接判超时。这两个参数在诊断规范里都会给出明确值开发时要把它配进协议栈的定时器表里同时在做自动化测试时按规范值去校验而不是用默认值一拍脑袋。6. 多帧传输背后的 TP 状态机SF/FF/CF/FC 拆包重组与定时器6.1 四种帧类型与 PCI 字段ISO 15765-2常说的 DoCAN 传输层简称 TP解决一个问题UDS 报文在经典 CAN 单帧里最多只能装 8 个字节数据超过 7 字节就必须拆成多帧。TP 定义了四种帧类型靠第一个字节的高半字节区分帧类型PCI 高四位载荷格式说明单帧 SF0000低 4 位表示数据长度0-7一条请求/响应数据能塞进一帧时使用首帧 FF0001第 1 字节低 4 位 第 2 字节组成 12 位总长度数据超过 7 字节时先发 FF 声明总长度连续帧 CF0010低 4 位是序号0-15 循环从 1 开始后续数据按每帧 7 字节继续发送流控帧 FC0011低 4 位是流控状态 FS后跟 BS 和 STmin接收方控制系统继续发或暂停举例测试仪读 VINECU 返回 62 F1 90 加 17 字节 VIN总共 20 字节超过 7 字节必须走多帧。ECU 先发 FFPCI 高四位为 0001总长度 200x014所以 PCI 两字节是 14高四位 1低四位 0 0x14这里不要被 16 进制绕晕首帧第一个字节高四位是 0001 表示 FF低四位是总长度的最高 4 位第二个字节是总长度的低 8 位。20 的二进制是 0001 0100所以 FF 的 PCI 是 0x01 0x14后面紧跟前 6 个字节的应用数据。然后测试仪回 FC0x30 表示 ClearToSend后面接 BS 和 STmin。假设 FC 是 30 08 14意思是允许你发 8 个连续帧帧间最小间隔 20ms。接下来 ECU 发 CF第一个 CF 的序号是 1PCI 为 0x21装第 7 到第 12 个字节再发 CF 序号 2PCI 为 0x22装第 13 到第 18 个字节最后一个 CF 序号 3PCI 为 0x23装剩余 2 个字节不够 8 字节的位置补 0x00 或 0xAA。到这里一帧 20 字节的 VIN 响应就传输完成了。6.2 发送与接收状态机的关键实现点多帧传输的实现本质是两个对称的状态机。发送方要管理发 FF — 等 FC — 发 CF — 完成这个流程接收方要管理收到 FF — 回 FC — 收 CF — 重组完成这个流程。发送状态机的关键状态可以这么划分空闲。收到上层下发的大于 7 字节数据检查长度不超 4095进入等待发送 FF。发送 FF记录剩余字节数和当前 CF 序号为 1启动 N_Bs 定时器进入等待 FC。收到 FC停止 N_Bs 定时器。如果 FS0ClearToSend按 BS 计算本块最多发多少个 CF如果 FS1Wait继续等待并重启定时器如果 FS2Overflow上层通信资源不足中止并向上报错误。每发一个 CF序号加 1按 STmin 做帧间延时。如果 BS 非 0 且已发够 BS 个数回到等待 FC如果 BS0表示一口气发完所有 CF。所有 CF 发完回到空闲。接收状态机的关键点在于收到 SF直接把数据交给上层不做重组。收到 FF检查声明长度是否超过缓冲区容量超过就回 FC 的 OverflowFS2并中止容量够就分配缓冲区保存长度回 FCFS0 或 1带 BS 和 STmin启动 N_Cr 定时器进入等待 CF。每收一个 CF校验序号是否符合预期正确则写入缓冲区并更新预期序号超时N_Cr 超时则中止并报错。已收字节数达到 FF 声明的长度把完整数据交给上层回到空闲。实现时最容易出错的是序号回绕。CF 序号是 4 位0x0F 之后下一个序号是 0x00很多人在状态机里直接写expectSn (expectSn 1)在回绕点上就会判断失败。正确做法是 (expectSn 1) 0x0F每次接收时做模 16 比较。另外BS0 这个取值有些特殊它表示接收方这次 FC 之后不会再发新的 FC发送方可以连续把剩余 CF 全发完。有些老协议栈实现里遇到 BS0 会一直等第二个 FC等不到就超时。如果你测试工具发的是 BS0而 ECU 一直没回完先怀疑一下 ECU 协议栈对 BS0 的处理是否符合规范。6.3 定时器是状态机不会卡死的保险丝ISO 15765-2 定义了几个关键定时器其中 N_Bs 和 N_Cr 在排障中最常用。N_Bs 是发送方发出 FF 后等待 FC 的最长时间默认 1000ms。超过这个时间还没收到 FC发送方必须中止本次发送并报错。N_Cr 是接收方发出 FC 后等待下一个 CF 的最长时间同样是 1000ms超时则中止接收。这两个定时器的意义在于总线上一个节点挂了、线断了、或者协议栈死锁不至于让其他节点永远等下去。联调时如果看到发送 FF 后 1 秒报超时基本可以判断接收方没有正确处理 FF或者资源被占满了连 FC 都回不出来。我会在协议栈里把这些超时事件打成带时间戳的日志输出到调试串口配合 CANoe 的 Trace 窗口一次就能定位是发送方的问题还是接收方的问题。7. 联调排障实录三个真实场景复盘7.1 场景一波形毛刺导致偶发 Bus Off背景是一台网关测试台架网关板子挂在一条 CAN 网络上和两个 ECU 开发板通信。现象系统运行几分钟后网关发出去的报文开始大量重发CANoe 统计里 Error Frame 数量飙升然后网关进入 Bus Off整个网络通信瘫痪要断电重启才能恢复。排查第一步接示波器看物理层。波形边缘有过冲和振铃幅度能到 1V 以上已经接近显隐性判定阈值。第二步查终端电阻。用万用表在总线两端量两端各接了一个 120Ω读数 60Ω这个没问题。第三步查分支。问题浮出水面——其中一个 ECU 开发板放在距离汇流排将近 1 米远的地方用两根细长跳线引过去既没有双绞也没有屏蔽形成了一个典型的长分支天线。处理方式把 ECU 板子挪近专用双绞短连线接到汇流排长度控制在 20 厘米以内。改完后再跑一整天Error Frame 归零Bus Off 再没出现过。这个案例告诉我们波形异常先查物理连接不要急着调软件而 Bus Off 这类看起来像软件问题的现象根子往往在物理层。7.2 场景二明明实现了服务却一直收到 7F 31 7F客户反馈某 ECU 的 31 例程控制服务没实现因为测试仪发 31 01 02 03 启动例程时ECU 回了 7F 31 7F。开发人员检查应用层代码发现例程确实写了函数入口也能进很困惑。进一步看 CANoe 抓的报文序列问题一目了然测试仪上电后没有发过 10 03 切换会话一直停留在默认会话。而规范里明确定义这个例程只能在扩展会话下启动。ECU 回 7F 31 7F 不是说服务不存在而是说当前会话不允许你得先切会话。这个案例的教训是UDS 开发里NRC 本身就是答案的一部分。看到 0x7F 或 0x7E先按会话状态 — 安全等级 — 参数范围的顺序排查不要默认代码有 bug。同时也提醒主机厂侧服务访问控制矩阵一定要写清楚哪个服务在哪个会话可用哪些还要安全访问解锁做成表格贴在开发和测试群里能省掉大量无效沟通。7.3 场景三多帧下载随机超时FF 发出后收不到 FC某个带 Bootloader 的控制器做刷写测试用 UDS 34/36/37 下载固件现象是偶尔卡住。CANoe 日志显示测试仪发了一帧 FF 声明要传 4095 字节的数据块ECU 那边一直没有回 FC直到 N_Bs 超时本次下载中止。一开始怀疑 ECU 收发中断被关掉了查协议栈代码没发现异常。后来在日志里注意到规律卡住的时刻几乎都发生在 ECU 刚写完上一块 flash 之后。ECU 的 flash 擦写是阻塞操作执行期间如果上层还没把上一笔 36 传输完成的状态清掉TP 接收资源就没有释放新的 FF 到了之后协议栈找不到空闲缓冲区又因为当前状态不允许回 FC直接丢弃了这帧 FF。测试仪这边看不到任何反馈只能等超时。根因找到后做了两处修改。ECU 侧flash 擦写时协议栈仍然保持接收能力至少在资源不足时回一帧 FC 的 WaitFS1而不是沉默测试仪侧36 传输的块大小从 4095 减到 2048并适当增大 STmin给 ECU 的 flash 写入留出余量。改完连续刷了 50 次没有再出现卡顿。这个案例有很强的通用性TP 层遇到处理不过来时宁可回 Wait 也不要沉默。沉默在测试仪端就是超时而超时的干预逻辑往往比流控复杂得多。协议栈里所有的不能处理分支都应该有一个显式的对外表达要么 NRC 0x78要么 FC Wait而不是让对面干等。8. 让协议栈从能跑到好交付工程化建议8.1 把诊断规范做成可执行的数据很多项目里 UDS 的 DID、RID、DTC 表都是散在需求文档里开发和测试各看各的经常出现代码实现和测试用例对不上。我的建议是项目启动就把诊断规范整理成结构化数据用 ODX 或 CDD 这类标准格式或者退一步用一张字段清晰的 Excel 表也行。服务子功能/DID会话限制安全等级正响应负响应常见NRC22 ReadDataByIdentifierF190 VIN默认无62 F1 907F 22 3131 RoutineControl0203 例程A扩展需要71 01 02 037F 31 7F / 7F 31 33有了这张表开发做代码生成测试做用例编写都是从一个数据源取数不容易漂移。至少在我经手的项目里这一步投入的维护成本非常低但省掉的扯皮时间非常可观。8.2 自动化测试要在冒烟阶段就介入诊断开发最怕的是临近交付才发现基础功能有问题。我通常建议测试团队在每一版软件出来时跑一轮自动化冒烟用 CAPL 脚本或者现成的诊断测试工具把下面这些基本项过一遍10 01 / 10 03 会话切换和正响应格式22 读 VIN、读软件版本号19 读 DTC 数量和快照14 清 DTC27 安全访问的 seed-key 流程3E 80 保活后 S3 超时回退默认会话每条服务在错误会话下发请求验证 NRC 是否符合规范这套冒烟脚本跑一遍只要几分钟但能挡住一大半低级但致命的回归问题。尤其是会话权限矩阵调整后漏改一个服务导致某条刷写流程卡住这种问题靠人工测试很难在第一时间发现。8.3 现场数据归档是隐形资产联调过程中抓到的示波器波形、CANoe 导出文件、协议栈日志我建议都按日期车型问题现象的格式归档不删除。一方面很多偶发问题和线束状态、电磁环境强相关今天抓不到明天可能就能复现另一方面新同事接手时这些历史捕获是无价的教材。最后分享一个我的个人习惯每次联调现场抓到异常波形或异常报文我除了记录结论还会顺手把这次排查用了几步、每一步看到了什么写进项目 wiki。下次再遇到类似问题哪怕不是我负责翻出这份笔记也能快速定位到那一两层。车载 CAN 和 UDS 这套东西本身不复杂复杂的是把物理层、数据链路层、传输层、应用层串起来查问题的那套手感。这种手感没有捷径就是多看波形、多抓报文、多复盘自己的判断错在哪。