通信协议标准FlexRay总线的功能安全性详解

通信协议标准FlexRay总线的功能安全性详解,第1张

  在汽车中采用电子系统已经有几十年的历史,它们使汽车安全、节能与环保方面的性能有大幅度的提高。随着研究的深入,许多系统需要共享和交换信息,为了节省线缆,就形成了依赖于通信的分布式嵌入系统。目前,世界上90%的都采用基于CAN总线的系统。FlexRay是下一代通信协议事实上的标准,它的功能安全性如何是至关重要的。

  1 IEC61508功能安全的要求

  目前车控系统正在向线控技术(xbywire)过渡,例如线控转向与线控刹车。线控系统最终目标是取消机械后备,因为取消这些后备可以降低成本,增强设计的灵活性,扩大适用范围,为以后新添功能创造条件。但是取消机械后备就对电子系统的可信赖性(dependability)要求大为提高。车是一个运动的物体,处于运动的环境之中,它因故障可能伤及自身及别人。取消机械后备,就将电子系统由今天的故障静默(failsilent)要求提升到故障仍工作(failoperaTIonal)的要求。

  国际上对工业应用的功能安全要求已制定了标准IEC61508,它主要关心被控设备及其控制系统的安全。虽然它也适用于汽车,但汽车不仅有上述功能安全问题,而且要关心由于功能变化造成的整车系统安全,所以汽车业内正在制定相应的标准ISO26262。汽车的功能安全等级分为4级,要求最高的是 ASILD,相应的失效概率<10-8/h,它相当于IEC61508的SIL3。根据实践经验,分配给通信的失效概率<10-10/h。有关这方面的介绍可参见参考文献。

  现在安全攸关的应用系统的范围有所扩大,以前不算在内的一些系统现在都要算了。例如安全预先动作系统(presafe)中座椅调整子系统、刹车辅助系统中的灯光控制子系统、碰撞后telemaTIc自动呼叫求援的子系统,都将视为安全攸关系统。

  1.1 引起系统安全风险的通信故障

  通信故障有5种表现形式,第1种是造成值域的错误。第2种是造成时域的错误,这是工业不同于民用的部分。一条消息不能在预定的时限前送达就失去了实用意义,例如与安全气囊引爆有关的传感器消息不能在数ms内送达就引起安全问题。在多播或广播通信中还有第3种错误:数据完整性错(拜占庭错),即各节点收到的结果不一致。它会引起系统性的失效,应对的策略必须将所有有关节点同时考虑。第4种是系统崩溃,除硬件失效外,也有干扰或软件引起的,例如饶舌错(babbling idiot)阻止通信。第5种是丢帧,短时间失效,例如可恢复的离线或bug引起的等效离线状态,又如小集团错。

  1.2 通信的容许失效率

  在通信故障对系统安全影响的分析上,参考文献提供了一种方法,根据瞬态干扰出现的可能长度,计算通信失效的时段长,在假定的通信失效率下,推出系统的失效率。在该实例中,路段上电场超100 V/m的区间有可能引起通信失效,失效率近似5×10-3,车速为90 km/h,识别出的可能失效时间约74 s。通信以6 ms为周期,连续7个周期丢帧视为系统失效,在此条件下系统失效率为1.640 9×10-10,认为可以达到SIL4的安全要求。这种分析方法是有效的,但是假设的条件太多,例如:误码率有很大的变化区间;帧长的变化影响一次传送的失效率;干扰持续时间的假定;连续丢7帧也与应用的场合有关,对90 km/h的车42 ms的失控对刹车系统而言有约1 m的距离,恐怕对撞击的后果有完全不同的评估;还假设SIL4完全分配给通信,将CPU与软件有关的部分失效率忽略不计,在软件规模越来越大的今天,这个假设是不合理的。另一方面,决定系统失效率时还应考虑其他的通信故障形式,例如出现小集团错到发生冲突的时间取决于相对的时钟漂移,越精确,其间时间越长,失效的时间就越长,参考文献中在人为制造出小集团后需300 ms才发现冲突,远远超出上述的42 ms。所以一般讨论系统安全的文章中都单独规定通信的失效率是相应安全等级失效率的1/100。

  1.3 影响通信失效率的因素

  功能安全等级与故障检测的覆盖率有关,如果有的故障未被检查到(未认识到或做不到),当然那种失效情景就不可能计算在内,安全等级的划分就有错。

  参考文献介绍了SFF(Safety Failure FracTIon)的概念:失效分为引起危害的失效和安全失效,它们又各分为能检测出和未检测出两种。安全失效比例SFF是能检测出危害失效与安全失效在总的失效中的份额。诊断覆盖率DC(DiagnosTIc Coverage)是能检测出的危害失效占总危害失效的份额。可导出SFF与DC有线性关系。而SFF又与SIL有关。IEC61508的SIL等级与 SFF有关,在SFF占90%~99%时SIL3可容许1个故障。因此DC也决定了能达到的SIL等级。根据有关文章介绍,瞬态故障的概率比硬件失效概率大2个数量级,因此可大致推断瞬态故障诊断覆盖率应达到90%~99%。危害失效可能由通信失效引起,诊断覆盖率也就成了评价通信协议的重要一环。

  在通信中,由于CRC有漏检,这是明显的诊断未覆盖区,诊断未覆盖率就相当于错帧漏检率,例如CAN的错帧漏检。

  在通信中发生值域错或时域错而丢帧是能诊断出的危害失效(这是本文分析的主要对象)。而假冒错、拜占庭错等应属于未检测出的危害失效。发生小集团错时既可能产生丢帧,也可能产生拜占庭错。CAN的等效离线失效也属于未覆盖的诊断引起的危害失效。要计算这些未覆盖的诊断引起的危害失效占总危害失效的比例还相当困难,因为确定故障概率模型很难。但从定性上讲,只有尽量排除假冒错、拜占庭错和小集团错,才能使诊断覆盖率提高(SIL等级提高)。

  2 FlexRay介绍

  由于线控技术可以提高车的 *** 控性能,降低生产和使用成本,提升安全性、节能、环保和舒适度,成为整车技术进步的重要一环。但是为了取消机械或液压的后备,对控制装置及其通信的可靠性的要求大为提高。这就对通信的带宽和确定性有更严的要求,CAN总线不能满足这个带宽要求,在确定性上也不足,于是就产生了 FlexRay技术。根据标准,FlexRay可以有总线、星型、树状等拓扑结构。它提供了双通道的控制器结构,可组态为冗余通信,也可各通道独立运行,有很大的灵活性。每个通道最高可组态工作于10 Mb/s。FlexRay是时间触发通信协议,由分布式时钟实现同步。系统的调度表由cycle\\static slot\\minislot确定。一个cycle有固定数目的static slot和minislot,它们的时间长度都是均等的,由组态时确定。一个节点在一个cycle中可以占用多个static slot,static slot可以散接(multiplxing),即各个cycle的同一static slot可以用于不同节点。FlexRay帧的数据域(payload)可达254字节,它的头部为标识符及帧长等控制信息,有独立的CRC检验,尾部有覆盖全帧的24位CRC检验。FlexRay有对抗时域错的Bus Guardian设计。

  关于FlexRay的缺点或弱点,参考文献提到物理层连接的困难,影响到信号完整性,实际上能较易使用的是有源星型,但这带来成本的提高;cycle设计约束多,带来困难;同步和启动节点配置与容错有关,是挑战;由于资源有限,升级演进时很困难(并非像以前强调时间触发协议的 composability优点——笔者注)。参考文献介绍了在FlexRay中产生各自独立的时钟同步小集团的可能性,也就是说虽然各节点都在通信,但是2个集团间无有效通信,是一种故障状态。解决办法是用3个冷启动节点、3个同步节点,但是这与时间同步容错的要求矛盾。还有就是将调度表排满,以免形成小集团,这也与留有余地供将来升级扩充的要求矛盾。总之尚无彻底解决方案。再有就是时钟可能产生同向漂移,与应用时钟的差造成帧未能就绪或覆盖引起漏帧。FlexRay虽然是为高可信性设计的,但是在传送中出错后处理要通过应用层解决,这带来新的问题,本文将分析如果不作处理会怎么样。

  3 Audi和BMW的FlexRay总线应用的功能安全等级

  BMW和Audi是首批批量使用FlexRay总线的车厂,它们的具体用法尚未查到,但是参考文献给出了部分使用参数,可以以此作一些初步分析。

  3.1 Audi的参数

  Audi的cycle为5 ms,每个cycle有62个static slot,slot用于传送42字节payload的帧,静态段为4.03 ms。有8个ECU共传送220个协议数据单元(PDU)。这些PDU经组合,最后在27个slot中传送。由提供的周期分布可见5 ms消息为8个,10 ms消息为1个,20 ms消息为7个,40 ms消息为6个,其余更长周期的消息先忽略。

  由payload可以算出使用的帧长为500位,假定误码率为ber=1×10-7(这在铜线中已是相当好的了),那么误帧率为fer=5×10-5/frame。

  由周期可算出每小时传送的帧数为n=7.92×105frame/h。假定通信用2个通道同时传送,那么同时失败的概率为fer2=2.5×10-9/frame。1小时内所有帧均成功传送的概率为:P=(1-fer2)n。

  1小时内有1次以上错的概率为1-P≈fer2×n=2.5×10-9×7.92×105/h=1.98×10-3/h。SIL2的安全等级要求是系统失效概率为10-7/h,分配到通信上为10-9/h,由此可见存在巨大的差距。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/dianzi/2502379.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-05
下一篇 2022-08-05

发表评论

登录后才能评论

评论列表(0条)

保存