CAN是应用非常广泛的现场总线。它已经被大部分汽车厂商用作车内控制器交换信息的通信干线，是分布式嵌入式系统的关键部分。但是它有一种以前未讨论过的与安全有关的故障，当某一处于消极报错状态的节点由于干扰而产生一个本地错后，因标准考虑欠周，该节点会与其他节点帧启停失去同步，在其他挂起待发的消息发送时不断出错，形成等同于离线的状态，无法提供服务，从而危及安全。本文讨论处于消极报错状态的发送节点，由于同样的原因失去同步后的演变过程。这里不同的是，因为标准中的另一个规定，它可能经历一个真正的离线状态。

1 CAN标准的安全漏洞

在讨论该问题时假定读者对CAN的标准已有充分的了解，由于中文译法的差别，本文采用的术语可能有所不同，相信不会影响读者的理解。在Bosch CAN2.O规范3．1．3款中说：“为了使报错帧正确结束，消极报错节点可能需要处于空闲状态至少有3bit时间(如果消极报错接收节点发生本地错)，因此总线不应满负荷运行。”——这是引起应用出故障的原因。因为节点问并无时间同步，即便总线有空闲时间，也不能保证像上述要求那样的分布。挂起待发的消息将在服务间隔(intermission，图中缩写为I．M．)后立即发送。这在规范中也有规定：“在另一条消息发送过程中挂起待发的消息在服务间隔后的第一位启动(发送)”。ISO11898标准没有提到3位空闲问题，但是CAN一致性测试标准ISO16845的具体条文会有这种要求(虽然该空闲要求还是不充分的)。CAN规定处于消极报错状态的节点在发现错之后发出6位隐位的消极报错标志(Passive error flag)，如读回6个连续的相同位时，就确认报错标志发完，如没发现6个连续的相同位，就继续发隐位，直到得到确认，然后开始消极报错帧分界符的发送。分界符从发出隐位读回也是隐位时开始计算，总共为8个连续的隐位。在CAN一致性测试标准ISO16845的7．5．6款与8．5．13款中，规定了接收节点与发送节点在发消极报错帧分界符时的格式错检查办法。它规定，在消极报错帧分界符开始后的8位中不得有显位；如有显位，就视为出错，开始新的报错帧。

如果一个处于消极报错状态的节点发现一个本地错(即有一种误判或漏判)，由于其他节点不发主动报错帧，那么它发的消极报错帧标志就不会及时得到确认，往往要到图1所示的数据帧或远程帧的EOF第5位才会得到确认；而它的消极报错帧分界符将延续到帧的服务间隔之后，它就和其他节点的帧启停失去了同步。其他节点开始新帧的SOF将被它视为格式错，而开始发新的消极报错帧。当其他节点有挂起待发的帧不断发送时，这个处于消极报错状态的节点一直处于不断出错的状态，不能发送也不能接收，即等同于离线状态。

这种源自标准考虑不周的故障会使CAN的优先级逆转(在处于消极报错状态的节点中的高优先级消息无法发送)；同时，基于优先级进行的调度分析失灵。以此为算法设计得到的消息最坏送达时间将是不可靠的，车的安全会受影响。在参考文献[1]中，讨论了修改消极报错帧分界符长度来解决该故障的方法。

2 处于消极报错状态发送节点本地错的后果

处于消极报错状态的发送节点在有本地错时，其行为倾向更差。标准ISO16845的8．6．9款对发送节点在消极报错帧分界符内的格式错规定了发送错计数器TEC+8，第7．6．12款对处于消极报错状态的接收节点在消极报错帧分界符内的格式错规定了接收错计数器REC+1。而且标准规定REC是有上限的，它不会导致节点成为离线状态；但TEC会一直加上去，当TEC=256时节点就成为离线状态，直到在总线上读到128个连续的11个隐位，然后它变为主动报错状态。因此弄清楚节点是接收还是发送的地位非常重要。

Bosch CAN 2．O规范3．2款对节点的定义是这样的：“开始一个消息的单元被称为该消息的发送节点。在总线空闲之前，或该单元在仲裁中失败之前，该单元一直是发送节点。”“一个节点被称为一条消息的接收节点的条件是：它不是该消息的发送节点且总线不空闲”。国际标准ISO11898-1：2003第4．18款有类似的定义：“发送节点是指开始一个数据帧或远程帧的节点，在总线再次空闲之前或在仲裁失败之前，它仍是发送节点”。第4．16款：“不是发送节点且总线不空闲时节点是接收节点”。标准考虑了如下几种情况：

①一个节点开始发送ID，仲裁失败，在此段时间里它是发送节点，而后它是接收节点。

②一个节点开始发送ID，仲裁胜出，发送完数据帧或远程帧，在整个发送时段及其后的服务间隔内，它是发送节点。

③一个节点开始发送ID，其中发生错误，或者在仲裁胜出后继续发送中出错，那么从开始到报错帧结束及其后的服务间隔内，它是发送节点。因为总线空闲最早在服务间隔之后。

④一个节点开始发送ID，仲裁胜出，发完数据帧或远程帧，但由于某种原因(EOF的最后一位为显位，或其后的服务间隔内第一、二位为显位)，接了一个超载帧。那么在整个上述时段及其后的服务间隔内，它是发送节点。

CAN协议没有考虑重复出错的情况：第一次是处于消极报错状态的节点发现一个本地错，其后是因为消极报错帧结束时与其他节点帧启停失去同步而造成新错。在图2中，处于消极报错状态的发送节点在ACK位发现一个本地错，它发的消极报错帧被其他节点视为EOF和服务间隔。其他节点发的新帧SOF被它视为格式错。该处于消极报错状态的发送节点无法见到它预期的服务间隔的结束，它就以发送节点的地位一直错下去。图3中，处于消极报错状态的发送节点在EOF部分发现一个本地错，其后续演化与图2相似。

只要有挂起待发的消息，此错就重复发生。由于发送节点的地位未变，它的TEC就一直加上去，直到TEC≥256，节点成为真正的离线状态。这不是本文第1节所说的等同离线状态。在离线状态下，如果能从总线上读到128次连续的11位隐位，它就可以恢复为主动报错状态。总线上不足11位的隐位将不被计入。因此，这种离线状态一般要长于参考文献[1]所说的等同离线状态。为了作比较，假定帧长均为含2字节数据的帧(66位)，在挂起的消息传送16次后，该处于消极报错状态的发送节点成为离线，即16×(66+3)=1 104位后离线；又假设最坏情况下有分散的10位空闲，那么节点处于离线的时间为128×(66+3+10)=10112位。该处于消极报错状态的发送节点发现一个本地错后，将有11 216位的时间不能正常收发。同样情况下，一个处于消极报错状态的接收节点发现一个本地错后在第一次遇到足够空闲时间时，其等同离线状态就会结束。

这种处于消极报错状态的发送节点变为真正离线的过程是无法从高层加以干预的，因为发送节点／接收节点的地位不是一个软件可控制的参数。

3 为什么需要消极报错状态

理论上，解决这一故障有三种可能的方案：第一种方案是，将消极报错帧分界符长度按一定的规则改变，使处于消极报错状态的节点发现一个错后总能与其他节点帧启停保持同步。在本文讨论的处于消极报错状态的发送节点变为离线状态的例子中，仅仅改变判断发送节点／接收节点的规则也是不够的，因为它仅能把可能的真正离线变为等同离线。所以随情况改变，消极报错帧分界符长度仍然是需要的。这一方案对应用的改动最小，仅CAN通信控制器芯片要修改。第二种方案是采用某种形式的CAN时间触发CAN协议，预留出一些总线空闲时间，使处于消极报错状态的节点发现一个本地错后仍能与其他节点帧启停同步；但是迄今为止讨论的CAN时间触发协议都缺少足够的纠错能力，它们都禁止CAN的出错自动重发机制，在出错后会导致数据的丢失。第三种可能的解决方案是，放弃消极报错状态，没了消极报错状态就没了消极报错帧，就不会有不同步的情况出现，也就不会有离线和等同离线的情况出现。

消极报错状态使通信控制器在正常工作与停工之间有一个中间状态，在此种状态下，它仍可发送和接收。唯一的差别是它的报错能力被限制到很小：只有发送节点在ACK以前的本地错会被其他节点知道。在其他情况下，消极报错帧不会影响其他节点的收发，不管这种错是本地错还是全局错。这样，如果这个处于消极报错状态的节点不正常，那么它对系统性能下降的影响就很小；如果它工作正常，则系统的性能没有损失。

对汽车类的应用来说，环境很恶劣，出错是不可避免的，然而在现场进行排障或修理是有难度或不可能的(例如上天或人海的应用)。在那里，能“跛”着回家是最好的策略。这种策略不仅适用于机械部分，也适用于工作失常的电子通信系统。消极报错状态符合这种策略。当车子在这种“跛”着回家方式下工作时，某些暂时性的故障有可能消失。例如，环境温度、电磁场、振动都可能因工况的不同或路段的不同而改变。随着通信恢复正常，节点的状态也可由消极报错状态回到主动报错状态。如果节点只有主动报错和离线二种状态，那么离线时节点就要不断测试通信是否恢复，或者等一段时间测试一下。显然，这些方法效率要低，不像消极报错状态时仍能提供服务，意味着提供服务的时间的减少。延长处于主动报错状态的时间，而去掉消极报错状态，会使有本地故障的节点对系统的干扰时间也延长。因此废弃消极报错状态不是一个好的选择。从Bosch CAN2．0规范里也可以体会到这一点：它规定一个处于消极报错状态的节点一定不得发主动报错标志。消极报错状态的想法也为FlexRay所采用，在它的协议运行控制部分规定有三种状态，分别是POC：NormalActive、POC：Normeal Passive和POC：Halt。

4 小 结

上述分析表明：处于消极报错状态的CAN发送节点在某些条件下会因一次误判而进入离线状态。其离线的时间一般比处于消极报错状态的接收节点因一次误判而进入的等同离线状态要长。为了避免这种类型的失效，最好的解决方案是采用可变长消极报错帧分界符，使消极报错状态的节点总能与系统内的其他节点保持帧启停的同步。在同步的情况下，假设现有CAN调度分析的理论没有大的缺失，例如没有此类故障，没有引起超载帧的条件，可以提供较为可信的结果。