tag 标签: 错帧漏检

相关博文
  • 热度 21
    2013-4-9 14:27
    2204 次阅读|
    7 个评论
    国家兴亡匹夫有责,从神九用到 CAN 总线讲起( 10 )错难补救   由于掌握了错帧重构的规律,所以可以说,你想怎样错就可以构造出怎样错的帧。 图 1 是一个数值被放大的例子,其中 U= x 8 +x 7 +x 6 +x 5 +x 4 +1, Ec=U*G= (1000, 0010, 0001, 1100, 1110, 1001) 。 Tx1 可以是以前连续 5 个 0 之后的填充位。也可以解释为 DLC0 ,例如原来是有 3 字节的数据,送一个 0000010000… 的值,结果错帧变为 1000010000… 的值,错帧将值放大了 32 倍。 图 1 错帧将数值放大 32 倍   观察图 1 的重构过程可见,如果将 Ec7 取为 1 ,那么 Tx7=0 ,错值倍数更大(为 64 倍),如果继续将 Ec8 取为 0 ,那么 Tx8=0 ,错值倍数更大(为 128 倍) … 。我们可以由修改后的 Ec 重新求 Uh ,例如为了达到 128 倍,由 Ec=1000010 ,将 Ec 除以 CAN 的生成多项式 G=(1100,0101,1001,1001) ,便可以得到 Uh=(x k x k-1 x k-2 x k-3 x k-4 x k-5 ) 。此时对照 5 种可能的 Ut ,我们可以选 k-4=5 ,即第 3 种 Ut 。得到 U=x 9 +x 8 +x 7 +x 6 +x 5 +x 4 +1 , Ec=U*G= (1000, 0100, 1001, 0111, 0111, 0100,1) 来重构出可疑数据流,如图 2 。因为算出的 Ec9 正好是 0 ,且 Rx7 由于有填充位设为 1 ,所以实际的放大倍数达到 264 倍。当然选其它 Ut 也是可以的,不过可疑数据流的位数稍多 1 位。   图 2 错帧将数值放大 264 倍   同样的多项式 U= x 8 +x 7 +x 6 +x 5 +x 4 +1, Ec=U*G= (1000, 0010, 0001, 1100, 1110, 1001) 。也可使值缩小 32 倍,如图 3 。   图 3 错帧将数值缩小 32 倍   在应用中数值的变化可能引起应用功能的错误,例如在变速器换档或刹车时,希望油门暂时减少,但是结果是加大,甚至可能全开。在丰田突然加速事件中,我是怀疑 VSC 经 CAN 传送到节气门的信号可能出错。美国的 NASA 调查报告并未排除使节气门开大的可能性。见文( 2 )。当然,并非一次传送错就会错到底,但是 CAN 存在短暂一段时间失效的可能性,这在我以后的博文中会交待。 这种错帧漏检之后跟着失效一段时间的危害是很大的,例如你在超车,你的转向角是 5 度,但是电动助力转向单元经 CAN 传到 ESP 的角度是 30 度,那么 ESP 认为这是驾驶员的命令,协助你实现 30 度转向, CAN 接着的几十毫秒失效,以及人不可能在几十毫秒内及时反应,你的车就可能冲到逆向车道了。   如果希望证实特定的数据变化,例如 Tx=10100101 是否可能变为 Rx=01011010 ,我们只要由这二项比较得到 Ec=11111111 ,将这个片断加上头部 Ech ,然后求出满足的多项式 U ,和以前的例子一样重构出 Tx 。不过,由于存在 Ec 的头部、尾部为特定形式的限制,这个可疑数据流不一定在你希望的位置,只有帧比较长时,帧的部分片断可以如愿重构。   错帧漏检的另一种危险是数据的相移,例如,你的帧内有许多表示状态和控制命令的开关量,一旦移相,状态和命令就乱了,有些保障措施也会失效,例如原来规定 55 表示开, AA 表示关,可以抵御有干扰时形成的非法码,现在由于移相, 55/AA 就会互相转换。混乱的状态和命令会产生设计时未预计到的系统状态,导致系统失控。   那么应用上有没有办法化解这一问题?对于这样的值域错唯一的办法是某种型式的冗余:软件上的冗余、物理上的冗余或时间上的冗余。   软件上的冗余就是另加数据的补充 CRC ,例如加一个 8 位 CRC ,这个 CRC 和原来的 CAN 的 CRC 没有共同的质多项式,此时可把漏检率缩小 256 倍,这样的结果还是达不到 Bosch 原定的指标。由于要占去一字节,在原来已用掉 8 字节数据的场合就比较麻烦:一帧要分为二帧。这都会增加带宽要求。其次是为取得不同接收节点的一致性,它们都要知道别人是否发现有附加 CRC 错,就要等有没有 NACK ,这要添加新的规定:例如必需在什么时限内发出 NACK ; NACK 的形式(否定哪个帧)。时限的引入也产生了延迟。 为了对付一个漏检的错帧,应用上的冗余要付出代价的,例如: 1 。原来用二个物理通道,只要有一个通道“正确”收到了就可以了。现在由于所谓“正确”可能是错的,当二个通道结果不一致时,你无法断定谁是真正正确的。就必须要有二个通道的第二次传送结果,在假定连续二次都发生错帧漏检概率小到可忽略不计的情况下,就可以以二次结果相同的通道作最终决定的输出。这样,通信需要的带宽要加倍, CAN 本来已为了减少竞争,把总线利用率定得较低,如 30%~40% ,这样做,有效负载降到只有 15~20% 。你为了满足余下的需求,要增加一套新的 CAN 系统,或者忍痛割爱,把控制闭环的采样周期加大,降低带宽需求,但也导致性能下降。 2 。原来一个物理通道时,你需要至少送 3 次才能作出表决。此时带宽的需求增到 3 倍,比上一条一样面临必须付出的代价。 3 。用对象输出变化的已知极限,拦截漏检的错帧,有时不可行。例如 Audi 方向盘角度传感器 G85 到 ESP 的信号本来应该识别 0-2000 ° /S ,这相当于 40 ° /20ms ,那么用拦截方案,变化超出 40 °就限值,但是由于传送值不是增量,方向盘角减少后的值(比上次采样小 40 °)在 CAN 传送中变大且被限值(比上次采样大 40 °),误差被限在 80 °,仍然是严重错误。 4 。接连多个采样值后作各种滤波,就像一般的抑制信号中干扰所取的办法,越是想抑制输入的干扰,就越要减少当前输入的权重。但这种办法完全不适用,因为原来的噪音只是信号范围的 1% 或更小,现在的错误值可能是信号范围的 80% 。要想抑制错帧,就会减少当前输入的权重到非常小,此时产生多个周期的延迟,就连累正常输入也有这样的延迟。若不想延迟,就要加快采样,把占用的带宽增加,而且不能完全消除错帧的影响。 这些方法显然会增加成本,增加重量、能耗,使设计、生产和维修变得困难,同时应用的性能仍然有可能下降。   这样的措施只能是克服困难的暂时性的不得已而为之的措施。就好比肚子饿的时候,先填饱肚子再说,饥不择食。我们总不能一直这样吧,因为这样总在付出别的代价。每一个人在作决择的时候总会有得有失,只是有的人看得远点,未雨绸缪,在长时间的刻度上损失小,有的人看得近点,只能委曲求全。不能说谁更高明,因为这只是目标函数的不同,约束条件的不同。而高明不高明往往是对约束条件的认识上的差别,有人认为做得到的事有人认为做不到。有人认为自己做不到,别人也做不到。有人认为自己做不到,也想不到去请别人来做,如此等等,诸葛亮的运筹帷幄,全在于他的审时度势,否则难有赤壁之胜,三国鼎立的局面。   有人会认为这是危言耸听,最好有实验数据来证实。这是非常朴素的实证观念,在简单的物理系统中常常是这样做的。但是在可靠性分析上,往往无法作这样的实验,把小概率的事件来作实验会非常费时间,就像文( 6 )讲的用软件注入求错帧漏检率会需要天文数字的时间。而像现在要求的功能安全要求的更小的概率,基本上只能用分析的方法。所以只能用分析的方法判断以前的分析有无错漏,而不可能以有限的实验的方法来判断以前的分析有无错漏。
  • 热度 23
    2013-4-7 10:37
    2015 次阅读|
    4 个评论
    国家兴亡匹夫有责,从神九用到 CAN 总线讲起( 6 )方法很关键   我们很多应用选用 CAN 总线是因为它特别可靠,按 CiA 的宣传资料是一千年才会发生一次错帧残留,按 Bosch CAN2.0 规范是帧出错率 *4.7*10 -11 。其中 4.7*10 -11 是错帧漏检率 Pun ,而帧出错率 *Pun 是错帧残留率 Pres 。一千年一次在我们有生之年是碰不到的,自然非常好,不过它这个值错了, 错误的数据会导致盲目乐观的态度 。   它的计算过程是:假定误码率为每 0.7 秒有 1 位错,当位时间为 2us 时,有 ber= 1/ ( 0.7*10 6 /2 ) =2.8*10 -6 并以此来计算公式中的 error rate 。这是简化的情况,与 Bosch 分析时采用的方法不同,在那里 error rate 相当于 bad 状态概率,例如分析时采用的为 10 -3 ,在帧长为 100bit 时,它的计算偏小了约 3 倍。   假定总线工作于 500kbps ,总线负载率为 40% ,平均帧长为 100 bit ,那么每小时送 7.2×10 6 个帧。按我的计算结果(见以后博文),错帧漏检率 Pun=1.15*10 -7 , 在 bad 状态概率为 1*10 -3 时错帧残留率是 1.15*10 -10 ,每小时的失效率是 8.82×10 -4 /h 。也就是每 1200 小时 =50 天要失效一次。如果像上面 CiA 介绍总线负载率为 100% 时,就会是每 20 天失效一次。   有人会说,我的系统从来没有失效过。说到数值问题,第一是你的系统可能干扰较少,在单帧长度为统计误码率时遇到的最坏情况远小于 1*10 -3 ,但是你不能否定别人的最坏情况可能达到 1*10 -3 ;第二,许多应用属于闭环控制,由于对象的响应比较慢,即使有错帧漏检,其引起的扰动刚开始就被新来的正确数据纠正了,你就没有感觉,但是你不能否定存在无法及时更新的可能性;第三,也许你在应用上还有别的纠错措施使错帧的影响减弱了,例如各种滤波算法,所以你感觉不到,但是你已经付出了相应的代价,例如降低了系统的动态指标。   现在说可信赖性分析方法。对整个国家而言,平均概率是重要的。但是最坏情况发生时,人身和财产损失对当事人是百分之百地已经发生。所以要按最坏概率作出发点。例如一,人的价值是无价的,所以欧美各国已进入到目标为交通零伤亡的时代,如果你的车不以此为目标,你就会在竞争中失败;例如二,有的项目全国都只有有限的数量,一次失效都是难以承受的,例如火箭卫星**之类。所以无论民用或军工都该以最坏情况作出发点。   关于错帧漏检的分析方法,据我所知大致有几种方法:第一是用软件仿真的方法,可以有控制地注入位错,然后按协议的规定检查,错帧是否溜过去,不过一般采取随机注入位错的方法,即一般随机测试的 Monte Carlo 方法;第二种是用分析方法,构造出会溜过去的帧,然后统计这种帧的个数,我就是用这种方法;也许还有第三种,用形式逻辑的方法来分析,不过我还不懂,不知道是否走得通。   Bosch 采用的是第一种方法。( J. Unruh, H.J. Mathony, K.H. Kaiser: "Error Detection Analysis of Automotive Communication Protocols". SAE Int. Congress, No. 900699, ?xml:namespace prefix = st1 /Detroit, USA, 1990. ) Bosch 对造成错帧漏检的二种原因均有论述,第一种原因是 CAN 位填充规则时出错发生部分数据流相位移动,第二次是出错又使相位又对上了,在有相移的部分造成收发数据比较时有大量差,超出了 CRC 检出错的能力;第二种是在定义帧长度的位中出了错,收发二边对帧长度有了不同理解,碰巧后边又发生位错,使变形后的帧通过了 CRC 检验和格式检验。关于这二种情况我后面都要用到,到时候详细介绍。   采用软件仿真的办法要求概率的分布是均匀的,而且样本的量较大,正是在这二点细节上这种办法是有缺点的,从而导致结果的准确度低。 首先出现漏检事件的出错位分布不是均匀的,发生在标识位等处的错会因数据移相,造成帧长变化而较易检测出来,不易漏检;而发生在数据域内的错则除了 CRC 检验没有其他检验可发现,易漏检;发生在帧尾部的错立马就被视作格式错,不漏检。 其次是样本的大小, Bosch 文章中针对的是 80~90 位的帧, CRC 检验的覆盖面为 58~66 位,这样帧本身就有 2 58 =2.88×10 17 种,注入的位置有 58×57/2 组,全部实例有 4.76×10 20 个。每一个帧在注入错前后要算二次 CRC ,还要做其他格式检查。例如有没有发生填充位错,有没有发生帧长变化导致格式错等。现仅就 CRC 检验来说:每个学过 CRC 计算的人都知道它要分很多步骤, 1989 年左右还是 16 位机的时代(例如 VAX11 系列),假定累加器由 A 构成,生成多项式为立即数 G ,步骤有 1. 如 A15=0 跳到第 3 步,否则进到 2 , 2.A 与 G 异或, 3. 进位位设新数据, 4.A 与进位位左移一位, 5. 判 CRC 覆盖区是否结束,如否则回到 1 ,如是就结束。 一位要循环 5 步,就算用机器代码,那时的计算机还只在 10M 左右,即 0.5us 。完成 58 位循环要 29us ,验算一条帧需 58us 。于是可以算出不停机运行一年可检验 365*24*3600*10 6 /58=5.43*10 11 条帧。全部实例有 4.76×10 20 个,可见测试的样本还不到实例的 10 -8 。即使当时的计算机速度估计不准,仍然是样本太小了。   样本小要作结论是无法置信的,例如 100 万辆车你遇到 1 辆性能很好就说车好,或者你遇到 1 辆车坏了就说车一塌胡涂都是偏颇的。   虽然 CiA 一方面推荐 Bosch 的残差值:出错率 *4.7*10 -11 ,实际上 CiA 还给出了另一个更大的残差值: CiA, CiA Draft Standard 304 V1.0.1 “CANopen framework for safety-relevant communication” ,第 26 页: The worst case residual error probability of the CAN protocol is P Re st = 7 * 10 -9 ,它来自一篇 Joachim Charzinski 的论文,在那里有: Pres7.2*10 -9 * q bad 。 所以他们自己已否定了 Bosch 的残差值。只是 CANopen 中的值还是比我的数据 1.15*10 -7 小了很多。
  • 热度 14
    2013-3-8 11:28
    2001 次阅读|
    1 个评论
    国家兴亡匹夫有责,从神九用到 CAN 总线讲起( 9 )知和识-2   n=(1 2 4 6 17 21 31); P3=2/107/106; Pun=0; for LTx=23:1:79       if LTx 30          P1=4*n(LTx-22)/2 LTx ;       else                     P1=15*2 -25       end temp=0;       for m=1:1:15              if LTx-m=49              temp=temp+(54-LTx+m)*2 -m                  else if LTx-m=64                     temp=temp+4*2 -m                     end end       end       Pun=Pun+temp*P1*P3 end 这样变化后的 LTX 部分或全部覆盖 CRC 域时的错帧漏检率是: 4.68*10 -8 。   由文( 7 )、( 8 )及上述数据我们可以得到: P un,2.0A = 6.89*10 -8 + 8.1*10 -11 +3.32*10 -8 = 1.02*10 -7 P un,2.0B = 6.89*10 -8 + 8.1*10 -11 +4.68*10 -8 = 1.15*10 -7   至此,由文( 7 ) ~ ( 9 )我证明了二件事: 1.CAN 的错帧漏检率要比 Bosch 声称的大 2000 倍; 2. 还有可能漏检的情况未分析,即可能更坏。   这些未分析的漏检情况有: 1 。 CAN 的帧开始位出错,由第二个显位开始的一段被错接收,引起变形帧,这个变形帧因第二个错,如同文( 8 )分析的那样,将数据读为 CRC ,成为短帧(见图 2 );或者将原帧的 EOF 读为数据,变为长帧。对这种情况下的错帧漏检概率我尚未深入研究。   图 2 SOF 错开始的漏检错帧   2 。已经计算的部分还有二个因素被简化了: 1 )还有 10 种尾部多项式未在这里提及,因为它们的贡献较小; 2 )在本文提到的重构可疑数据流的二个位错中间,还存在容许添加多个位错(图 3 ),只要它们不在连续的可能形成填充规则窗口中,就不会形成新的数据移位,这种情况的贡献尚未详细研究。在本例中如果第 3 个位错发生在 Tx13 处可以, Tx14 处就不行。   图 3   U=x 6 +x 4 +x 3 +1 , Ec=U*G=(1110 , 1111 , 0101 , 1010 , 0000 , 01) 多位错的情形   这表明上述计算的结果还是保守的,还不是最坏的。   2011 年推出的 CAN FD 将填充位也计入 CRC ,此时就 CRC 来说不存在收发数据的移位,也就不可能因 2 位错而漏检。但是, CAN FD 为了与 CAN 兼容,在数据域长 8 字节以内时完全用 CAN 的规定,即用原来的 15 位 CRC 及其不计填充位的 CRC 计算方法。这种继承就把错帧漏检率大的缺点也继承下来了。 兼容的方案曾使 intel 和 Microsoft 在 pc 上大获其利,电子工程专辑论坛中的 "ARM 与 X86 的战争史诗 " 写得很好( http://forum.eet-cn.com/forum_post_10005_1200241710_0.htm )。我在 pc 刚开始时根本没兼容的概念, 86 年买了一台不完全兼容的 Sanyo 550 pc ,结果是没软件可用成了废物一堆,这才知道兼容的重要。不过当兼容成了接受家族遗传病时就是另一会事了,这时需要的是壮士断腕的决心了。 Bosch 是这样描述 CAN FD 与 CAN 的关系的( CAN FD Specification v1.0 http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf p.3 ) : " 只要不用到 CAN FD 的格式, CAN FD 和 CAN 的具体实现可以相互通信,这使 CAN 系统可以逐步过渡到 CAN FD 。在 CAN FD 的引入阶段,可能只用于特定的工作模式,例如终端编程时的软件下载,此时不支持 CAN FD 的其它控制器处于待机状态。“ CAN FD implementations that are designed according to this specification and CAN implementations that are designed according to the BOSCH CAN Specification 2.0 can communicate with each other as long as it is not made use of the CAN FD frame format. This enables CAN systems to migrate gradually into CAN FD systems. In the introductory phase, it is possible to use CAN FD only in specific operation modes, e.g. software-download at end-of-line programming, while other controllers that do not support CAN FD are kept in standby. 于是可以知道,他们期待最终将 CAN 系统过渡到 CAN FD 系统,我们 可以设想有二个结果: 1 。过渡结束就完全用 CAN FD 的长于 8 字节数据的格式,以免遇到原有的错帧漏检问题,这时你会需要修改软件,例如不用部分加填充,就像以太帧最小帧长的处理方法; 2 。为了仍保持短帧的优点,修改 CAN FD 协议,统一长短帧的 CRC 计算方法,废弃目前 8 字节内数据按 CAN2.0 校验的 CRC 方法,此时你的软件不用改,但是你的硬件要升级。无论何种方案,你的升级还要分二步走,先走的人会吃亏。   写到这里,我想到我们中国人口中的知识一词,它可分为知和识,如果我不知道 CAN FD 的细节,我是无法断定它为了与 CAN 兼容也继承了 CAN 错帧漏检率大的缺点。但是如果我不想一想,就没人告诉你,还有那些可能影响 CAN 以及 CAN FD 的情况,所以不要只做知道分子。现在国内的书籍往往是以厂家的宣传资料或 databook 为依据编写的,而厂家往往出于自己的利益,将优点说得很充分,对问题不会提及,或者轻描淡写一笔带过,只有在有竞争的方面才会互揭软肋。现在各生产 CAN 芯片的厂家在 CAN 协议上的利益是相同的,所以没有竞争,同病相怜,没法说缺陷,所以作为用户在作重要决定时一定要自己想明白。 对我的博客也是这样,我告诉你的是我的想法,我当然想说服你,但是未必没有疏漏与错误,所以我也希望你能深思,诚恳地欢迎有心得的朋友提出不同的观点,我们 就事论事,互相促进 。
  • 热度 23
    2013-3-8 11:22
    2039 次阅读|
    5 个评论
    国家兴亡匹夫有责,从神九用到 CAN 总线讲起( 9 )知和识   在文( 7 )中分析存在于数据域的可疑数据流,但是 CAN 的位填充规则适用的范围还不止这些,本文分析可疑数据流部分或全部覆盖 CRC 域的情况(图 1 )。可疑数据流的一部分 Txb 进入了 CRC ,而 CRC 余下的部分用 CRCb 表示。 图 1 可疑数据流对 CRC 的覆盖   我们在数据域内划出一小段 15 位的连续空间 A ,它的位置可以在数据域内非可疑数据流的任何地方,它的前后有数据块 B1 、 B2 。根据 CRC 计算的的原理,总的帧长的 CRC 校验和是各分段 CRC 校验和的异或的结果。所以对选定的可疑数据流, Txa 是已知的,假定任取 HB1B2 (这表示一个串,其对应位置各为 H 、 B1 、 B2 ,未定义的位置全为 0 。各位置的 x i 多项式阶次是不同的,所以串在一起时只要把多项式相加),在串后加 Txa ,得到 HB1B2Txa ,有一个相应的校验和 CRC1 ( 15 位),我们可找到合适的 A ,使串 HB1AB2Txa 的校验和( 15 位)正好有 TxbCRCb ( 15 位)。因为串 HB1AB2Txa 是 HB1B2Txa 和 A 组合成的,设 A 的校验和为 CRC2 ( 15 位),故有 CRC1 + CRC2=TxbCRCb 。显然,已知 TxbCRCb 和 CRC1 , CRC2 就是确定的。而根据文( 7 )图 3 介绍,已知 CRC2 就完全可确定原来的数据 A 。对应一个 TxbCRCb 就有在特定位置的唯一的 A ,这里在特定的可疑多项式覆盖部分 CRC 域时,只有覆盖部分的 Txb 是已知的, CRCb 可以任选,就可以在特定位置对应多个 A 。这些情况就构成了概率分析的基础。   发生可疑数据流部分或全部覆盖 CRC 域的情况时,错帧漏检的条件有如下几项: 1 。可疑数据流占同长度数据的比率(包括不同头部形式、尾部形式); 2 。对应可疑数据流覆盖 CRC 位数,存在的数据 A 的数目占 A 可能的数据的比率(包括 A 在数据域内可取得不同的位置); 3 。位错发生在特定位置的概率。   由文( 7 )式( 3 )每一种长度的可疑数据流 LTx ,在 LTx 〉 =30 时有 3*2 ( LTx-27 ) 种,有 4 种头部形式和 5 种尾部形式,每种 LTx 长有 2 LTx 种可能的数据流,所以可疑数据流占同长度数据的比率为 P1=4*5*3*2 ( LTx-27 ) /2 LTx =15*2 -25 。 LTx 为 23~30 时如表 8 所示。这里 P1=4*n(L)/2 LTx 。 由 CRC2 确定 A 时存在概率问题。假定 A 在数据域内的位置已设定,因为 CRC2 中只有 Txb 几位是固定的,那么 A 有多个取值,如用指针 m 表示 Txb 的位数,那么 CRC2 就有 2 15-m 种,对应的 A 也有 2 15-m 种,而 A 为 15 位,所以合适的 A 的比率为 2 -m 。而 A 可以处在数据域内未被可疑数据流占用的部分任意位置,位置空大小为 64-15-(LTx-m)=49-LTx+m 。即使位置空为 0 ,也可以算一次,所以合适的 A 的比率为 P2=(50-LTx+m)*2 -m 。当 LTX 比较大时,若留在数据域内还很多,不足以留出 A 需要的 15 位空间,那么就无法靠 A 来产生漏检条件,所以要求 LTX-m+A=64 ,即 LTX-m=49 时才算。 8 字节数据域的帧帧长为 107 位(不计填充位),发生 2 个位错的位置组合共有 107*106/2=5671 种,所以位错发生在特定位置的概率是 P 3 =1.76*10 -4 。 于是我们得到的漏检概率 Pun 计算程序为: n=(1 2 4 6 17 21 31);         % 由表 8 得到 P3=2/107/106; Pun=0; for LTx=23:1:64       if LTx 30          P1=4*n(LTx-22)/2 LTx ;       else                     P1=15*2 -25       end temp=0;       for m=1:1:15              if LTx-m=49              temp=temp+(50-LTx+m)*2 -m              end       end       Pun=Pun+temp*P1*P3 end 运行结果为 3.32*10 -8 。   特别要提一下,对 CAN2.0B 来讲,在 ID 中有一个连续的 18 位,这个区间可以放置上述 A 块。此时 LTX 可扩大到整个数据域与 CRC 域,即 LTX=79 ;由于 A 块不再在数据域,计算的条件“ LTX-m=49 时才算“分为二种,当 LTX-m=49 时 LTX 和 A 均可在数据域内,移动的次数由 (50-LTx+m) 再加 ID 内移动 4 次。当 LTX-m=64 时 A 在 ID 内,移动次数为 4 次。于是我们得到 CAN2.0B 的漏检概率 Pun 计算程序为:      
  • 热度 39
    2013-3-4 20:29
    14140 次阅读|
    23 个评论
    国家兴亡匹夫有责,从神九用到 CAN 总线讲起( 8 )不要迷信   这样细节的讨论对没有花力气读过 CAN 原理的人可能比较吃力。为此简单介绍一下 CAN 的帧结构: CAN 的帧由头部的仲裁域、控制域、数据域、 CRC 校验和、认可域和帧结束部分( EOF )构成。仲裁域主要是消息的标识符,不同优先级的标识符同时出现在总线上时,优先级最高者胜出,就按帧的剩余部分继续发送,而竞争失败者停止发送,转为接收者。控制域内有 4 位,决定数据域的字节数。   CAN 帧的查错措施中对发生在控制域的位错是靠 EOF 的设计实现的。其原理是规定填充位规则只管到 CRC 结束处,而 EOF 部分为连续的 7 个 1 。当控制域发生位错时,原来传送的帧长被误读,产生了变形的帧。如果变形帧长于原帧,那么原帧的 EOF 部分将落到变形帧的数据域或 CRC 域,由于 EOF 部分破坏了数据域或 CRC 域的填充位规则,接收节点就查到错,在 EOF 第 6 位处发报错帧。如果变形帧短于原帧,那么接收节点会在期待的 EOF 部分收到原帧的数据或 CRC ,就不会有连续的 7 个 1 ,接收节点就会发现不满足 ACK 分界符或 EOF 部分的格式错,从而在 EOF 的任一个位置(查到错后的一位)发报错帧。由于这种机制,不但有接收错的节点不会产生错收,也保证了系统内所有节点的一致性。   但是当有第二个位错时,这一机制存在漏洞。图 1 中发生在传送 EOF 第 5 位的 1 如果有位错,那么 EOF 部分和数据部分的区别就不再存在。变形帧就存在漏检的可能性。就可以理解为收到了有填充位的数据 F1 ,或者由于正在送数据 F1 的填充位时出了错,被理解为收到了期待的 EOF 。 图 1 数据流和 EOF 部分发生误解的条件   图 2 是 DLC 由 0111 变为 0011 的例子( DLC2 传送中由 1 变为 0 ),长帧读为短帧: 图 2   DLC2 传送中由 1 变为 0 时帧的变化 此时原帧的第 6 个数据字节具有图 1 中 F1 的值,其填充位在传送中出错变为 1 ,从而使变形帧读为 Ack+EOF ,格式是符合标准的。对任意 H*D1D2D3 总存在一种 C1*C2* ,它满足 CRC 检验及其分界符的格式检验,所以出现变形帧通过 CRC 检验的概率是 2 -16 。对 D6 即 F1 来讲,只要前 7 位为 0111111 ,就能保证接收节点在填充位传送出错时 EOF 的格式检验通过(因为 CAN 规定接收节点的格式检验只到 EOF 第 6 位)。所以 F1 出现的概率是 2 -7 。 7 字节的帧, 11 位标识符可能有 2 个填充位,自 DLC1 到 CRC 结束共 73 位,可能含 18 个填充位,帧长最多为 119 位,原帧二位错发生位置的组合有 119*118/2=7021 种,所以发生在 DLC2 及 D6 填充位处错的概率为 1/7021=1.4*10 -4 。这一情形下的漏检概率为 Pun=2 -16 *2 -7 *1.4*10 -4 =1.69*10 -11 。 节点收下变形帧后,如果有新帧发送,它会干扰其它节点对原帧的收发,从而引起报错,但是这种后果已经影响不到该节点已经收下的帧。   这种漏检的情况还有;数据由 6 字节变到 2 字节( DLC2 传送中由 1 变为 0 ), Pun=1.69*10 -4 *2 -23 ;数据由 8 字节变到 0 字节( DLC3 传送中由 1 变为 0 ) Pun=1.21*10 -4 *2 -23 ;数据由 4 字节变到 0 字节( DLC2 传送中由 1 变为 0 ), Pun=2.55*10 -4 *2 -23 。总的错帧漏检率为 Pun=8.1*10 -11 ,仅此一项,它已经大于 Bosch 声称的漏检率 4.7*10 -11 ,所以不要迷信外国。   说到迷信,从字面上讲,就是自己不动脑子,只要是权威说的就不加思考地接受了,这当然省事,因为有了事可以推托:外国人也是这样的,我们水平低,能不错吗?这样的态度无异于认为我们是****。我认为为了把我们的事做好,每个数据都应审核一下,也许过去没有发现错,才办了错事,那确实是当时认识水平不够。但今天已经给你指出了问题,就不要再推托了。 现在国际上在推行汽车的功能安全标准 ISO26262 ,那么对于以前已经被安全认证过的东西,是否要因为新发现了有安全漏洞而推翻呢?我认为功能安全的概念中有重要的一条,即功能安全存在于整个产品的设计、生产、维修生命周期中。新发现有错表示原来的安全指标分解过程有错,不能被确认( Validation )了,自然要重新确认,否则搞什么认证和确认都是假的了,只留下粉刷现实的印记而已。希望管事的人不要叶公好龙。   现在谈谈 CAN FD :这是 2011 年 Bosch 推出的可变速率的 CAN 升级版本,它仍然声称在安全性方面错帧漏检率是 4.7*10 -11 。   Total residual error probability for undetected corrupted messages: less than message error rate * 4.7 * 10 -11 . 但是在它的二种速率交替时,会有慢速读取高速位流而出错的情况,形成第 3 种错帧漏检机制。详见:杨福宇 , “有关 CAN FD 的评论“,《单片机与嵌入式系统应用》, 2012,   No.7 , p.34-36 , 40 。它在实质上与本文是一样的,第二个错造成误读为 EOF 。 CAN FD 在 DLC 的值大于 1000 之后定义的帧长变化是大于 4 的,所以长帧读为短帧出现的情况要多许多,同样可用上述方法分析。只是因为帧长加大,二位错发生位置的组合数变得很大,从这个角度使第三种错帧漏检率降下来。