文章总结： 文章详解汽车CAN总线Busoff机制：TEC>255触发，32次错误帧即可Busoff，干扰单一ID可能因成功报文抵消致次数增多；给出快恢复10ms×32次、慢恢复60s及DTC确认策略，强调连续性与OEM差异，为车载通信故障诊断提供工程参考。 综合评分： 86 文章分类： 车联网安全,应用安全,技术标准,安全运营,解决方案

CAN通信：Busoff问题知多少

谈思实验室

2026年1月24日 18:02 上海

以下文章来源于开心果 Need Car ，作者开心果 Need Car

开心果 Need Car .

号主：开心果 Need Car，主要从事汽车Autosar开发，公众号主要分享 通信、诊断、存储、网络管理、标定、Bootloader等工程开发问题。致力于将学到的知识，分享给更多的Autosar从业者，努力解答一线开发工程师的困顿！

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

01

测试中，为什么是32个错误帧出现一次Busoff？

Busoff的产生是因为TEC（Transmit Error Counter）＞255导致，再次提醒：与REC（Receive Error Counter）无关。也就是说，如果节点状态切换到Busoff，是因为节点自身外发报文错误导致TEC＞255。回顾一下节点状态机，节点状态机如下所示：

在切入主题之前，对Error Passive状态做一个展开，节点由Error Active进入Error Passive，是因为REC＞127 or TEC＞127。所以，节点进入Error Passive状态的可以分两个层面看：

• 第一、总线上其他节点（eg:Node A）引发的错误，导致接收节点（eg:Node B）的REC＞127。既然是外因，即：Node A错误导致Node B进入Error Passive状态，对Node B的最大”伤害”到此状态即可，Node B的通信状态没有什么问题，无需断开总线连接；
• 第二、发送节点引发错误，当TEC＞127时，进入Error Passive状态，如果发送节点依然识别到自身发送报文有问题（有错误帧），为了降低对总线上其他节点的影响，发送节点要为自己的错误行为负责，当TEC＞255时，节点需要暂时退出总线通信，之后尝试恢复通信。

对于节点的Error Passive和Busoff状态，驱动层可以提供对应的接口给上层，以此改善功能算法。以英飞凌tc3xx为例，如下所示：

如果需要更进一步的知道Error Passive是TEC还是REC导致的，可以进一步读取错误计数寄存器（ECR）的RP位域，如下所示：

提示：REC使用7个Bit表示，最大可表示128，TEC用8个Bit表示，最大可表示256。

回到这个小节的问题：“测试中，为什么错误帧达到32帧，就会Busoff呢？可以大于32帧吗？”

如果要搞清楚发送多少错误帧会导致TEC＞255，进而让节点进入Bus off状态，我们需要先清楚TEC的累加规则：

1. 发送节点在发送时，产生错误标志，TEC + 8。注意，有两种工况除外：
2. 第一、仲裁阶段，节点发送隐性位（”1″），收到显性位(“0”)。当其他节点CAN ID小，优先级高时，低优先级（CAN ID大）的节点仲裁失败，发送的隐性位被显性位覆盖导致；
3. 第二、节点处于Error Passive模式时，Ack Slot发送隐性位，收到隐性位（没有节点应带发送节点），说明当前总线只有一个节点在总线中，此时TEC不需要再累加；
4. 发送节点在发送主动错误标志或者过载标志时，检测出位错误（Bit Error）, TEC + 8；
5. 节点从主动错误标志、过载标志的最开始检测出连续14个显性位。之后，每检测出连续8个显性位。TEC + 8；
6. 被动错误标志后检测出连续8个显性位。TEC + 8；
7. 发送节点正常发送完一帧数据，且被其他接收节点应答（Ack）。TEC – 1，如果TEC = 0，则保持0；
8. 如果节点已经Busoff，当检测到128个连续11 bit隐性位时。TEC = 0。

通过如上规则可以看出，对于发送节点自身发送报文导致的错误，TEC均会累加8，也就是说，如果想最快地使得某个节点进入Bus off状态，就得让发送节点自己识别到自身产生的错误，而且，最少要产生32次，32*8 = 256 ＞255，节点进入Bus off状态。

有的时候看到总线错误不止32帧，节点才进入Busoff，又是因为什么呢？这里我们分析一种工况：

测试中，如果通过Capl脚本只是干扰节点（Node A）固定的CAN ID(eg：0x10)，可能需要＞32个错误帧，才能让Node A进入Bus off。一个项目中，一个节点的外发报文可以有多个。假设：Node A有5个外发的周期性应用报文，CAN ID：0x01~0x20，周期都是10ms。测试中，只干扰CAN ID = 0x10的报文。

如上TEC计数规则中，节点每成功发送一帧报文，TEC会减1，由于Node A 的5个CAN报文周期相同，干扰0x10使得TEC + 8，但是，如果其余4个报文成功被发送，则每发送一帧，TEC – 1。这样就使得TEC不能很快的＞255，进而错误帧的次数会超过32帧。所以，如果想快速的制造Bus off，可以对多有外发报文的某个Bit干扰，这样，可以连续的干扰出32个错误帧。

只干扰特定CAN ID报文，总线报文状态示意如下所示：

提示：一个错误帧中，可能有多种错误类型。

02

Bus off的DTC问题

当Bus off发生到一定程度时，会影响到总线的正常通信，需要将此故障信息记录下来，以便于后续问题排查。对于Bus off DTC的设计策略，每家OEM要求有所不同。本文，分享一种需求，供大家参考：

1. Busoff检测频率10ms。DTC一般会对应一个或者多个事件（Event），为了识别事件的状态，会约束一个检测频率，检测频率的大小，意味着事件发生故障时，能否被快速检测到，进而决定着事件对应的DTC能否被快速触发；
2. Busoff快恢复32次，快恢复周期10ms。当节点通信出现故障时，如果能快速恢复通信，节点功能也能及时恢复，所以，设计10ms的快恢复也就能理解。尝试32次，也是想尽可能地挽救故障节点的通信功能;
3. Busoff慢恢复NA（不做明确约束），慢恢复周期60s。当快恢复32次都不能有效挽救节点通信时，说明节点大概率出现了不可逆的故障。所以，设计一个较慢的慢恢复期，就是想再碰碰运气，万一节点通信又恢复了呢？如果节点不能恢复通信，车辆又不能立马停下，只能任其不断地尝试慢恢复，因此，不做慢恢复的约束。此时，同网段内的其他节点会监控对应的通信报文是否丢失，故障节点由于发生Busoff，非Busoff DTC的监控功能禁止；
4. Busoff发生32次，进入慢恢复期时，Bus off DTC Confirmation（Bit 3 = 1）。既然做了最大努力的尝试，节点不能恢复通信，为了便于后续的车辆检修，需要记录Bus off DTC；
5. Step Up = 4，32次Busoff后，4*32 ＞127，Step Down = 128。

相对于其他监控事件，Bus off 事件优先级（Event priority）一般较低，注意：1表示highest priorit，数字越大，事件的优先级越低。

这里需要讨论一个“连续”问题，Busoff发生32次，且Busoff由快恢复（Level1）进入慢恢复（Level2）阶段时，Busoff DTC需要上报。这里的32次如何计算呢？这里抛一个问题：”如上需求中，10ms可以检测一次节点Busoff状态，假设前100ms检测到了10次节点Busoff状态，中间1s节点恢复了通信，之后又快速的发生了32次Busoff，需要上报Busoff DTC吗？“，如下所示：u

如上的问题就涉及到了一个问题：”Busoff次数如何累加？“，对于这个问题的答案，需要结合项目需求，和甲方明确好。每家OEM的约束不同，这里讨论一种约束工况：以10ms检测频率为基准，如果20ms的检测周期内没有检测到Busoff，则Busoff CNT不再累加，重置Busoff CNT（Busoff CNT = 0），因为此时的Busoff不是”连续”的。

来源：

https://blog.csdn.net/tjcwt2011/article/details/144292975?spm=1001.2014.3001.5502

谈思-汽车出海安全合规（欧洲）

交流群

谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台，以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流，都将通过本平台为您提供持续支持。社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。

谈思-SDV&AIDV技术出海

交流群

诚邀行业同仁加入谈思SDV&AIDV出海技术交流群，聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题，欢迎大家加群交流探讨~~社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自：

新势力车企：

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上)：

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：谈思实验室 《CAN通信：Busoff问题知多少》