国家兴亡匹夫有责(14).doc_第1页
国家兴亡匹夫有责(14).doc_第2页
国家兴亡匹夫有责(14).doc_第3页
国家兴亡匹夫有责(14).doc_第4页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论