1、国家兴亡匹夫有责，从神九用到 CAN 总线讲起（14）抛砖引玉从网上阅读的体验来说，我和许多人一样，对评论与哲理性的文章的兴趣大于纯技术性的文章，因为技术性的内容往往有别的渠道可以得到，而那些哲理心得的文章是可遇而不可求的。我的文笔难以出彩，所以主要是技术性的，我之要写出来是因为我没有精力把它纳入常规的渠道。比如写书会耗大量的精力，还不知道会有多少人看，与其这样，还不如能写多少算多少，有多少人看就算多少，不争朝夕，仅为同道交流而作。可信赖性的要求已经深入我们这代人的日常生活之中，对于要作安全攸关系统用途的通信协议就更必须从设计上加以审视。由于现场条件的制约，通信总会或多或少地出错，什么时候能发
2、现错，出错之后怎么办，这是通信协议首先要考虑的问题。CAN 总线的驱动器是线“与”性质，当总线上有 1/0 冲突时，只要 1 位的时间，发送“1”的节点就知道了，这个特点也可用来报错，任何认为要发送报错（任何原因引起的错都可以，只是现在 CAN 只用来送数据链路层发现的错），就可以发“0”来通知别的节点。这是非常重要的特点。现在来看别的总线的驱动器。每个节点在发送时都可通过回读总线上的电平来观察有无冲突。例如 A,B 二个节点发送冲突的值时，总线上的模拟电平会有不同的分布，靠近发送节点处总线仍以特征阻抗方式作为负载，读回的值仍在输入的范围内，仅当对方的信号到达时，叠加的结果可能会引起读回值的错
3、误，由于采用的位速率较高，A 受到的冲突是 B 在传输时间以前发送的值，例如 AB 二点相距 20 米，传输时间约 100ns，每一位为 100ns（即 10Mbp s），那么 A 发送 10100,B 发送 01011时前 4 位正好错开一次传送时间，AB 都见不到错，到第 5 位时才发现错，所以存在发现错的时间的不确定性。但是处在中间的节点有可能出现输入阈值的过渡区，出现接收中有格式错或CRC 错。如果距离更大，传送的时延更大，这种发现错的不确定性更大。此时用总线上造成冲突来实现报错的方法就非常复杂，时间上会涉及许多 bit，要厘清正常数据与报错信号很困难。现在假定有节点发现了接收错，它就
4、面临 2 个问题：1。如何让别的节点知道，以保证一致性？2。如何避免丢数据而影响应用的安全性？现在有些通信协议采取冗余传送同一信号的方法，来回避出一次错的问题，例如 FlexRay 有二个通道来送。但是二个通道同时出错的概率仍不能忽略，在假设 ber=1*10-7，对 BMW 和 Audi 的应用例子算出的失效率均在 10-3/h 以上，远低于 10-9/h 的要求。（参见杨福宇,“Flexray 总线的功能安全性分析“，单片机与嵌入式系统应用，2011, No.12，p.8-11 ）。学通信时我们知道误码率是与信噪比有关，现场采取的抗干扰措施总是越强越好，假定都采取了同样的抗干扰措施，此时误
5、码率就与信号的能量有关，10M 的信号比 1M 的信号能量要小 10 倍（如果它们的幅值相同），很难想象 FlexRay 的误码率比 CAN 小。在不纠错的方案不行的情况下，就必须有专门的报错帧与重发机制，这就带来了新的难度。由于错是“偶而“发生，如何分配带宽给报错帧？能立即安排报错帧吗？不能立即安排时，每个有关节点在什么时间之前必需等待，以判断是否有报错帧（等待时这个帧不该被应用调用）？这个等待时间又与调度方案有关，它对应用的消极影响如何折衷？对应一个帧要一个等待计时器，后续的帧又要有各自的等待计时器，一个节点要考虑多少个等待计时器？在硬件上要增加多少？等等均十分棘手。所以从这个方面来讲我认
6、为 CAN 十分优秀，只要解决前面讲的错帧漏检、不当离线、不一致性问题，它就很完美。可惜的是，没有人重视这三个要害问题。说这三个问题是要害，从我的博文中的许多举例可以证明，CAN 是已暴露的安全问题的疑犯（博文（3），（4），（12），（15）。这些在丰田突然加速事件和大众死亡闪烁事件中的CAN 失效的直接证据不是专业人员特意找到的，而是普通消费者无意中提供的，可以说如果这种无意间提供的信息中已经含有 CAN 失效的直接证据，那么在4S 店处被遗漏或疏忽的 CAN 失效的直接证据实际上应该更多。现在的新潮是 CAN FD，有没有问题？下图表示 CAN FD 正常位速率（slow bit）的接收
7、节点在重同步（Resync）于高位速率发送节点后，有可能读到（Samp）1 的情况（只要高速位（ fast bit）在第 n+1 位是 1（R ）。在采样后的第一个 0 引起新的重同步，然后仍可能读到 1。对低速接收节点而言，每位读错的概率大致为 2-1。错读为合法的ACK DEL 和 EOF 的概率为 2-8。CAN FD 在接收节点读 DLC 任一位时有局部错，例如应为 24 字节而读为 8 字节，它将提前进入 ACK，成为低速率工作。因 DLC 有 4 位，只考虑 0 变 1 之错，其概率为 ber*4/2。如果已收到的部分数据 m 满足 CRC 检验条件，该节点将发 ACK，在错读 A
8、CK DEL 和 EOF 的条件下收下此帧，成为漏检错帧。只要 m 大于 39 位，总存在一个满足 CRC 及格式检查的后 22 位，所以此种情况出现的概率是 2-22=2.3*10-7，总出错概率为 2-8*ber*4/2*2.3*10-7，ber=10 -4 时为 1.8*10-13。考虑到传送速度提高之后每小时的帧数会很多，那么每小时的失效率会很高，例如以 5Mbit/s 传送，帧长为200bit，总线利用率为 40%，每小时传送 3600*5M/200*40%= 3.6*107 个帧。接收节点所发 ACK 会干扰发送节点，引起发送节点报错，但存在不干扰的概率为 2-5。所以 CAN F
9、D 漏检错帧引起的失效率是 1.8*10-13*3.6*107*2-5=2*10-7/h，远大于要求的 10-9/h。即使把 CAN FD 仍用在低速 1Mbit/s，每小时送帧 7.2*106个，CAN FD 漏检错帧引起的失效率是 1.2*10-6/h，也还是远大于要求的 10-9/h。ResyncSampD*1 lowbitf2012 年推出的 CAN FD 在解决错帧漏时对原 CAN 的短帧采取完全兼容的方案，也就是继承沉疴（即使只用低速时，也还有本博（8）：不要迷信：的错帧漏检隐患），而且在二种速度时，发生 DLC 位错时，会出现以慢位速读快位速的情况，存在新的错帧漏检机制（见上节）
10、；在消极报错状态下因一次局部错而不当离线方面（本博（11），（12）完全不当一回事；在 EOF 部分最后第 2 位局部错时（本博（13）造成的一致性问题上无所作为。所以CAN FD 未解决要害问题。在安全隐患未解决的前提下再说 CAN 或 CAN FD是如何可靠，就是忽悠人了。所以 CAN 这个优势如何发挥是一个未解决的问题。CAN FD did not address three main known safety faults that are high residual error rate, long quasi and real bus off status due to just
11、one local error and inconsistent receiving due to a local error in last- but-one-bit of EOF. Hence its use in critical application which should satisfy function safety requirements is questionable. 我经过多年研究对这三个问题均找到了改进方案，目前暂时保密（即使我game over 也不会绝了）。2007 年大飞机项目上马前，退休工程师周济生（退休前是中航一集团下属中航商用公司原副总设计师，有着 37
12、 年的航空从业经历，先后参加过运十、AE100 飞机、ARJ21 支线飞机的设计工作）牵头的民营广东昌盛飞机设计有限公司期望加入大飞机部分工作，却无人问津，可见进入的难度远大于技术的难度，这是现时无法徊避的问题。但也有企业自行立项成功的例子，例如飞豹、歼-31。要自主开发类似 CAN 的通信协议也会面临同样情况，中国还在向市场经济的转变过程之中，急不来的，就待它自行发展吧，但技术上的难度是有壁垒的，现时是买不来的，因为国外也没有！其中第三个问题尤为艰难，国外有多种解决办法，但均十分复杂耗时，有的方案原理上就不能成立，例如 Majorcan 的方案认为只要过了 ACK 与 CRC 不报错就可认为
13、没错了，其实忽略了 DLC 错引起帧长不同的情况（可参见本博文（8）。这里抛砖引玉，看看我的解决方案中的二个次要内容。尽管略为次要，与CAN 或它的继承者比，也会对可信赖性（Dependability ）的改进大有颇益，从而增进信任。第一个例子是 ACK 功能的取消。在 CAN 中凡是接收节点成功收到，就要发 ACK，如接收 CRC 未通过，就在 ACK 分界符后报错。这是重叠的检查。设想只有一个接收节点，它没坏的话，接收正确时就发 ACK，不正确接收时就有报错。如果它坏了，无法发显位，那么接收正确时就发不出 ACK，不正确接收时就不会有有报错，发送节点对 ACK 和没有报错的判断都是会错误的
14、。所以 a)发送节点是无法用双重检查来检测出接收节点的错的。b)发送节点自身有很多查错措施，靠没有 ACK 的反馈来查自身错是不可靠的：发送节点只有在位错未发现的情况下，才会等待接收节点无 ACK 来查自己的错。例如发送节点要写1/0，实际写 0/1，读回时错为 1/0 的情况下，发送节点不能发现错，如果接收节点确实发现了错而未发 ACK，总线上为 1，发送节点仍可能错读为 0，所以靠有无 ACK 判发送节点有无错是判不出的。如果有多个接收节点，如接收全对，就不会有报错；如接收全错，就不会有 ACK，但一定会有报错；部分对时，会出现既有 ACK 又有报错的情况。对发送节点而言，只要有报错，就得
15、重发。所以 ACK 可以没有，报错（实际上是 NACK）必须保留。取消 ACK 可以减少开销，也便于实施提高位速率的设计，例如类 CAN FD。第二个例子是报错资格的限定。在 CAN 中任何一个发现有错的节点均可以发报错帧，其实是不必要的，而且带来不利的影响。实际上不是目标接收节点，它错不错是没有关系的，如果它因为局部错（例如靠近它的电缆的地方临时有一些干扰）而报错，目标接收节点却没错，那么这个不必要的报错就伤及目标接收节点和发送节点，使目标接收节点的应用因重发而延迟了时间；使发送节点出错计数器加上去，恶化了健康状态；使系统增加了报错与重发所需的流量。我的方案是在仲裁区任一节点发现错可报错，过
16、后，只有与 CAN 滤波模板相符的节点有错才可以报错。其它节点有错可以统计错误，但不报错。这样做可以大大提高系统的可用性。例如一个系统有 n 个非目标节点，误码率为ber，帧长（29 位 id)约 140 位（包括填充位），n 个节点原来的不必要报错机会是 n*140*ber，现在是 n*29*ber，不必要报错可能性降低到原来的 29/140=20%。上述 3 个缺点都得到改进。CAN FD 未去解决问题，实在是为有志开拓的人们留下了大好机会。别人正在销售给你的和准备销售给你的 CAN 就只能这样了，要么继续冒生命的风险，要么没有可用的替代品，现实的需求放在那里。我是自以为是摸了一块过河的石头。我知道山外有山，天外有天，人外有人的道理。我的精力比不上年轻人，又是半路出家，学识上不及各位硕士、博士、教授、专家，所以特别是希望你们能指出我这些文章的研究中的漏洞，我的判断是否正确？这是不是我们面临的困境与机会？如何取得共识？如何推进研究与设计？如何协作？也希望各位做出各自的 CAN 的改进方案，或是缓解 CAN 缺陷影响的方案。尽管立项等是难题，但仍然可以在学术上探索，为我们中国车与运载工具性能的提升出份力。很多专家已是超负荷，分身乏术，并没有时间来细细研究我说到的这些问题，时间的短缺迫使他们采取随大流的作法，但这是有风险的，跟错了技术平台，丧失商机的例子也是屡见不鲜的。
