CAN 总线Babbling Idiot 问题研究

杨 康，张凤登

（上海理工大学光电信息与计算机工程学院，上海 200093）

0 引言

目前大部分汽车电子控制单元间的底层通信协议以CAN 总线为主。CAN 总线本身没有处理Babbling Idiot 故障的机制［1］，一旦通信节点发生Babbling Idiot 故障就会影响节点间通信。汽车对实时性和安全性要求很高，是不允许在通信期间发生Babbling Idiot 故障的，所以研究CAN 总线Babbling Idiot 故障并提出有效的解决方案具有非常重要的实际意义。

目前关于Babbling Idiot 故障的相关研究与文献数量较少。Bosch 标准规定可以利用CAN 本身的错误约束机制在一定程度上缓解该故障。当出现错误时，CAN 节点就发送一次出错帧，错误计数器加8，节点重复发送出错帧并持续累加计数器直至总线报文传输正确。每当完成一次正确报文接收与发送，CAN 节点的计数器就会减1。若一直发送错误帧，节点计数器不断累加8 直至超过255，该节点就会进入Bus Off（离线）状态［2］，脱离总线。CAN 总线本身的纠错机制使Babbling Idoit 故障只持续一段时间并终止，但对于汽车这种高安全行业来说还不够迅速。Broster 等［3］提出了基于事件触发的CAN 总线监守模型，该模型灵活度较高，开销小，采用同步时钟，能防止故障节点静默后导致的总线时钟不同步；Buja［4］提出用一个总线监守控制CAN 通信控制器向驱动器进行输出的方法，在发消息前由主机的应用程序向总线发申请，该消息在总线空闲时竞争发送。总线监守到某个时间后禁止通信控制器向驱动器进行输出，切换下个消息进行竞争发送，由此给每条消息提供一个属于自己的时间段进行发送。总线在设定的时间范围内持续监听数据帧，判断是否发生Babbling Idiot 故障，然后告知相关节点并禁止其发送，所以省去了节点消息发送的请求；Vahid 等［5］针对Flexray 提出总线监守方案，将Buja 在CAN 总线的方法移植到Flexray 总线中；付道俊等［6］和赵琳等［7］针对CAN 总线提出了冗余的硬件方法，保证了总线网络的负载均衡；周康等［8］针对CAN 总线中存在的各种软硬件问题设计了迅速检测与定位的模块。

1 Babbling Idiot 故障定义

CAN 总线若在某一空闲时间有多个节点同时发送报文，根据CAN 总线的CSMA/CA 媒体访问机制进行仲裁，通过对每个报文的标识符判断对应的优先级［9］，优先级高的进行发送，优先级低的退出并进入等待队列。在发送结束后，若高优先级报文的发送节点因为软/硬件问题或干扰并没有与总线断开连接，该错误节点会不停地发送错误帧至总线。由于帧格式均正确，所以CAN 总线只能默许错误帧不停发送而无法进行自我修正。根据CAN 总线的仲裁规则，任何优先级比它低的报文将被持续堵塞直至故障解除。这种情况对于汽车这种安全性要求很高的行业将会导致灾难性后果。因此，无论何种原因导致的Babbling Id⁃diot 都必须迅速得到解决。

1.1 软件导致的Babbling Idiot 故障

当总线上发生软件Babbling Idiot 故障时，通常会影响某个节点发送低优先级消息。在帧格式等协议上节点传输的报文无异常，但CAN 通信帧会出现无意义数据场情况。这种错误有时是由于技术人员引起的，如软件编写的BUG 或者是网络攻击、病毒软件等。不论哪种原因引发的Babbling Idiot 故障，使用总线监守方法都能有效解决该问题。在CAN 总线上，当一个通信节点与其他节点信息交互时，可以使用节点本身故障静默的方式处理正在发生的Babbling Idiot 故障。为阻止错误节点蔓延到总线监守上，需要将总线监守模块与总线物理模块分离并进行电磁屏蔽，给它提供一个独立的电源与晶振。

在Robert 等［10］的时间触发（Time-Triggered）协议里，只有节点处于自身通信的时间段才能访问总线，此时总线监守的工作量相对于事件触发协议是很小的。如在安全性要求较低的情况下，若发生Babbling Idiot 故障，只需要很简单的操作就可以使节点停止发送接收消息。Robert 在TTP/C 协议中提出总线监守的目的是一个状态机，建立一个逻辑设备和4 根连接到主控制器的通信线，还有一根连接到收发器的通信线。

但是静默故障节点这个方法在事件触发（Event -trig⁃gering）协议中实施起来不太容易。节点空闲的时间访问总线和带来冲突的低优先级消息会造成传输延迟，任何总线监守方法都必须考虑到最坏的消息传输时间。一种定义最小抑制时间和安排通信任务的方法如下：除了在抑制时间，该节点有权在任何时间段访问总线，其基本原理是当某个节点发生Babbling Idiot 故障时，由于该节点处于抑制时间而不能和其他节点通信，所以接收不到Babbling Idiot错误帧，这种策略已经应用到CAN 中。总线监守是建立通信控制器和收发器作为一个辅助节点来保护被监守节点，它只能读取总线上的报文但不能进行任何更改操作。其工作方式是检查报文的标识符，当总线监守检测到被保护的节点传输报文过于频繁时就断开节点收发器。这种解决方案非常有效，但有两个缺点：①总线监守的复杂性，因为它有嵌入式网络协议，因此布置该监守节点较为复杂；②故障检测功能不完善，无法检测Babbling Idiot 节点传输的消息标识符为不正确或错误帧消息情况。Buja 等［11］提出了该缺点的解决方案：将输出节点与总线监守的通信控制器连接，而不是与总线连接。

1.2 硬件导致的Babbling Idiot 故障

使用总线冗余解决硬件Babbling Idiot 故障是较为有效的方法［12］。一个CAN 总线网络由两个信道构成，每个信道都有各自的收发器，使用两个信道发送相同的数据。该方法的两个通道物理分离，电气绝缘，两个收发器也相互分离。当其中一个通道发生Babbling Idiot 故障时不会影响另一个正常通道。通过这种方式使硬件的Babbling Idiot 故障节点不阻塞CAN总线网络和节点，即节点表现为故障可操作。

时间触发协议如TTP/C、FlexRay 和SafeBus 都提供了总线冗余［13］（前两个用于开发线控驾驶应用程序，后一个用于航空航天应用程序）；TTP/C 与FlexRay 是两通道冗余，SafeBus 是四通道冗余。基于以上协议的总线利用冗余功能传输帧，达到覆盖该Babbling Idiot 故障的目的。然而，简单的总线冗余并不能有效解决基于事件触发协议中的Babbling Idiot 故障，如CAN 总线传输的报文具有的不确定性。事实上，比较两个通道的数据流并没有意义［14］。因为总线访问受仲裁位裁决，不可能保证两个通道消息的顺序永远是相同的。因此，要解决事件触发类总线硬件Bab⁃bling Idiot 故障，不能简单使用传统的总线冗余。

2 Babbling Idiot 故障解决策略

2.1 FlexCAN 模型及总线监守

FlexCAN 模型通过提高CAN 总线协议的安全性与可靠性满足安全需求，采用应用软件修改，成本不高易于实现。使用商用市场常用的硬件部件，对硬件唯一的要求是主控制器可以驱动两个或多个独立的通信控制器。

FlexCAN 依赖于复制的节点（副本）和通道。作为一个整体，副本构成一个容错单元（FTU）。容错单元的副本之间有主节点、辅助节点层次关系。在一个运行系统中，只有主节点有权发送消息，其他副本监视其行为。如果次节点在预定时间间隔内没有在任何信道中接收到任何消息，则假定主节点失败并开始作为主节点发送信息。如果副本（主副本除外）未通过任何复制通道接收到消息，则认为主节点没有故障。通过这种方式可以轻松地支持总线复制，这种节点的层次结构可以通过算法实现［15］。

除初始化阶段外，当容错单元（FTU）中的节点相互发送和接收“组间信息”（特定于应用程序的数据和其他信息，例如协议时间同步信息）时，所有FlexCAN 节点的通信时间相同，并且在周期内不会重复发送消息的标识符。Fl⁃exCAN 在开发控制中最重要的FTU 应用类型有：传感器FTU、控制器FTU 和执行器FTU。传感器FTU 是系统的输入设备，它被配置为第一个软件链路；第二个软件链路是控制器FTU，它的任务是接收传感器发送的信息，进行一些计算并传输结果；执行器FTU 是系统的输出设备，是软件链中的第三个环节。它接收来自控制器FTU 的参考数据并执行，向控制器FTU 发送反馈。FlexCAN 可以容忍单硬件的Babbling Idiot 故障，与信道或收发器引起的胡言乱语故障没有区别。硬件Babbling Idiot 的故障被解码成一系列错误帧，破坏了信道通信。假设硬件Babbling Idiot 故障是非传播性且不影响复制的信道，则正确的通信可以继续［16］。

总线监视器是一个简单的逻辑设备，连接到主控制器，如图1 所示。通信控制器的输出（Tx）和总线监视器（BS）连接到或门。反过来，或门的输出（Tx）连接到收发器的输入端。

通信控制器和总线监视器共同控制传输，在FlexCan架构中，不考虑主辅节点的时间误差；当通信控制器传输消息时，总线管理器从启用变为抑制传输，在这种情况下，所有其他节点检测到一个错误发生，如CRC 错误、填充错误或其他错误类型，就通过通信网络传输错误帧［17］。

总线监守通过两根导线与主控制器连接：一个用于发送信号，从主控制器连接到总线监守（TxReq），另一个反馈信号至CAN 控制器（BsFbk）。总线监守还与CAN 控制器的输出一起作为或门输入，控制CAN 收发器工作，其工作方式是：主控制器在传输前需要向总线监守发送传输请求，在一个给定的时间间隔后，总线监守抑制或允许通信。TxReq 和BsFbk 物理连接到微控制器端口Port 的两引脚，以两变量的状态组成Port 口的状态变量，即Port=［BsFbk，TxReq］。总线监守和主控制器使用独立的时钟，因为他们操作不需要同步。

总线监守算法的工作状态主要有4 种，如图2 所示，通过Port 口赋值确定当前的运行状态。下文结合图2 阐述该系统状态机的工作原理。

状态1：总线监守抑制传输。主控制器没有发送消息，这种情况下，Port=0，TxReq=0，BsFbk=0 和BsEn=1（值为1 是抑制功能，值为0 是通信使能）；

状态2：主控制器通过设置TxReq=1，即Port=1，请求通信。如果inhibit_time 抑制时间已经结束，通信使能，总线可以正常通信，即BsEn=0；

状态3：总线监守通信使能。通过BsEn 清0 和通过置位BsFbk，允许主控制器进行发送操作，此时Port=3，启用主控制器传输消息；

状态4：数据传输完成后，主控制器清除发送请求TxReq，此时Port=2，进入空闲状态。

Fig.1 Implementation of bus supervisor图1 总线监守实现

Fig.2 Bus supervisor state machine图2 总线监守状态机

2.2 CAN 总线标识符可变策略

Can 总线标识可变策略是将低优先级节点通过提高优先级的方法来发送消息，防止一直被高优先级的报文阻塞。在发送消息之后，该节点优先级会恢复。Can 总线标识符可变方法如下：当一个节点试图访问总线但由于其优先级低而无法访问时，其节点中的优先级计数器将递减，在该节点的阻塞过程中持续减少，直到节点可以访问总线并恢复其优先级。

选取5 级节点作为案例研究。节点优先级A 最高、E 最低，依次降序排列，优先级数值越大优先级越低，如表1 所示。在第一个时隙里，A 和D 都有信息要发送，但在这个时隙访问总线的是A，因为它的优先级高。在下个时隙里无节点要发送报文，D 的报文在此时发送。同样，在第三个时隙里，B、C、E 要发送报文，最后B 的报文被发送。E 节点在第三个时隙里要求访问总线，然而由于它的优先级低，不断被高优先级任务阻塞，导致节点E 在接下来的8 个时隙里不能成功访问总线，如表2 所示。

Table 1 Priority level and number of examples表1 优先级级别和编号例子

Table 2 Priority arbitration based on CAN bus表2 基于CAN 总线优先级仲裁

如表3 所示，前两个时隙相同，但在第三个时隙里C 和E 不能访问总线，但是CAN 总线标识符可增加这些节点的优先级（减少他们的优先级号码），在下一个时隙里继续判断他们能否访问总线。在第四个时隙里，节点E 的优先级号码为10-1=9，C 为6-1=5。在这个时隙中，C 的优先级高，节点C 访问总线，访问完后节点C 的优先级号码还是之前的6。在第五个时隙里，节点E 的优先级是10-2=8，节点A的优先级是2，所以A 访问总线。在第六个时隙里，B、D、E三个节点要求访问总线，节点E 优先级号码是8-1=7，B 的优先级高所以访问总线。在第七个时隙里，节点E 优先级号码是8-2=6，D 为7，因此E 访问总线。节点D 在CAN 总线第七个时隙标识符与CAN 总线的第七个时隙标识符相比，提早了4 个时隙。

Table 3 Variable bus priority arbitration based on CAN bus identifier表3 基于CAN 总线标识符可变总线优先级仲裁

3 实验验证及结果分析

3.1 CAN 总线标识符可变策略验证

为了验证该策略的可行性和可靠性，本文采用3 个案例进行对比分析和验证，每组5 个节点分别命名为A、B、C、D 和E，每个节点的功能含义见表1。第一种情况见表2 和表3，第二种情况见表4 和表5，第三种情况见表6 和表7。

CAN 总线与CAN 总线标识符的系统延迟时间比较结果见表8。从表中可以看出，采用可变CAN 总线标识符策略后的最坏情况是第一种情况。变量CAN 总线标识符和CAN 总线上每个节点的延迟时间相等，另外两种情况都比CAN 总线的系统延迟时间短，因此该策略是可靠的。

Table 4 The second case is based on CAN bus priority arbitration表4 第二种情况基于CAN 总线优先级仲裁

Table 5 The second case is based on CAN bus identifier variable priority arbitration表5 第二种情况基于CAN 总线标识符可变优先级仲裁

Table 6 The third case is based on CAN bus priority arbitration表6 第三种情况基于CAN 总线优先级仲裁

Table 7 The third case based on CAN bus identifier variable priority arbitration表7 第三种情况基于CAN 总线标识符可变优先级仲裁

Table 8 Comparison results of system delay time between CAN and CAN bus with variable identifier表8 CAN 和CAN 总线标识符可变两者的系统延迟时间比较结果

CAN 与CAN 总线标识符变量性能比较结果如表9 所示，表9 说明采用CAN 总线标识符变量策略的所有总线系统在3 种情况下延时时间分别缩短了9.3%，12%，21.5%。

Table 9 Performance comparison results of CAN and CAN bus identifier variable表9 CAN 和CAN 总线标识符可变两者的性能比较结果

3.2 实测与评估

通过实验评估总线监守功能。使磁悬浮系统运作后，控制小球不断调整位置，通过vector 的工具CANoe 持续进行报文收发。在系统工作进入稳定状态后，通过编写CA⁃PL 脚本让最高优先级的CAN 报文在某一节点不间断发送，使系统进入Babbling Idiot 状态。看到Trace 窗口出现RxErr帧后监测到Babbling Idiot 故障。在没有总线监守功能的系统中，发生此类故障后，CAN 总线不能有效自主地解决这个故障，导致总线通信一直被阻塞。在引入总线监守模型后，再次重复制造Babbling Idiot 故障，在总线监守模块将故障节点与总线断开后系统便恢复了正常通信。图3 是在CANoe 中监测到正常运行情况下磁悬浮小球的帧数据信息，可以看到小球位置信息帧、PID 相关参数帧以及磁悬浮设备相关参数帧。

采用稳态误差来评估系统性能稳定情况。在CAN 总线的Babbling Idiot 故障解决后，用系统的稳态性能作为该系统评价指标。图4 为消除故障后系统稳态时的曲线，该曲线的误差值在［-1.5%，1.5%］之间，因此系统是较为稳定的。

Fig.3 Frame data information without Babbling Idiot fault图3 无Babbling Idiot 故障时帧数据信息

Fig.4 Steady state curve of magnetic levitation ball control system图4 磁悬浮小球控制系统稳态曲线

4 结语

本文针对汽车常用的CAN 总线存在的Babbling Idiot故障进行分析，对软件因素进行研究，提出总线监守方法检测通信节点，避免发生总线阻塞导致的严重后果。另外还提出了可变标识符方法，通过使其自减，使得在总线通信拥堵时在一定程度上缓解拥堵，改善总线通信能力。但是本文对于硬件原因产生的Babbling Idiot 故障未作深入研究，仅使用了双冗余方法采用两个CAN 控制器，未讨论如何保证总线监守模型一直正常运行，保证自身不发生故障。对于影响监守功能甚至主动造成节点静默的问题还有待进一步研究。