智能汽车“软肋”:被忽视的电控安全

读懂财经
关注

/ 02 /域控制电子电气架构的安全挑战

在分布式电子电气架构中,车辆不同功能由不同ECU来控制。而不同汽车功能的汽车电控元件,都有着不同的功能安全等级以及处理优先级,其软件和算法甚至必须运行在不同的底层实时系统上。

而集成式电子电气架构,原本由多个ECU完成的功能,现在需要依靠单一的域主控处理器来完成,还需要管理和控制所连接的各种传感器与执行器等。这就对硬件和软件均提出了高度要求。

具体来看,以往ECU软硬件结合负责单一功能,但在集中式架构中,软件和算法被“收归中央”,整合到域控制器上,这必然会导致域控制器的软件体系更为复杂,也会导致整个软件系统的出错概率增加、可靠性下降。这一问题虽然能够通过硬件虚拟化技术进行分区处理,但复杂软件系统本身的不可靠性依然未能完全解决。

更重要的是,在汽车电子系统中,不同应用对其实时性和功能安全等级要求差异巨大。如根据ISO 26262标准,汽车仪表系统与娱乐信息系统属于不同的安全等级,具有不同的处理优先级。这也很好理解,在汽车行驶中,娱乐信息系统死机或重启并不影响驾驶安全性,但汽车仪表系统出错却会在一定程度上对司机驾驶安全造成巨大威胁。事实上,汽车仪表系统突然失灵事件,在当前新能源汽车上并不算罕见。

又如特斯拉电动汽车备受争议的“单踏板”模式,一个加速踏板控制车辆的加速和减速,由同一传感器和处理器控制,但是在理论上,加速功能的安全等级应该远低于刹车功能,至于动能回收,则处理优先级更是远低于加速功能。

这也是集成式电子电气架构的关键问题,即如何保障软件系统的可靠性。但截止于目前,关于汽车电子电气架构软件系统鲁棒性的第三方测试却完全缺席。

汽车,毕竟不是手机。无论技术多么先进,汽车作为一种出行工具,其第一要义即在于安全性。时至今日,手机系统失灵、死机现象仍然屡见不鲜,各种小BUG更是层出不穷,我们已经司空见惯。但是,对于汽车来说,一个BUG出现,或许就是严重的安全事故。

/ 03 /软件和算法的“车规级”迫在眉睫

在汽车制造领域,有一个重要名词叫做“车规级”,用来形容汽车零部件的专用标准。

如车规级芯片,对温度要求需要达到-40~125°C,而消费级芯片仅需满足0-70°C要求即可。前者出错率必须为0,而后者出错率仅需满足<3%即可。在使用上,车规级芯片需要满足15年使用要求,而消费级芯片仅需使用1-3年时间。

可以看到,车规级产品有着远高于消费类产品的标准要求,这也是基于汽车使用环境带来的高安全标准。

实际上,车规级本身即是一批汽车厂商联合制定的行业标准。但是,在智能汽车方兴未艾的新阶段,行业内对于智能汽车的新形态上却缺乏严格的标准制定。

例如在智能座舱芯片上,部分车企并没有采用车规级解决方案,而是采用消费级芯片改装转换而来。但这毕竟是智能座舱芯片,其安全等级并不算高。

不过整体而言,汽车硬件上问题并不突出,而软件和算法目前尚处于标准缺失的空白地带。

随着汽车电子电气架构变革时代来临,车企们纷纷开启了自研软件和算法。在这一领域,虽然有着ISO 26262功能安全标准约束,但在汽车企业激进的架构设计上,软件算法的功能安全却始终缺乏有效的保障。在汽车上,一旦算法出现问题,汽车很容易就会出现违背驾驶员意志的失灵,导致不可挽回的结果。

更为重要的是,某些软件或算法的BUG出现相当随机,在仿真测试或者真车实验中或许根本难以显露出来。

这正是目前集成式电控系统面临的关键挑战。事实上,这一问题也并不复杂。对于车企来说,优先级更高、安全等级更高的功能,至少应该保持更为独立的系统。在关键功能上,至少将最高权限还给驾驶员自身,而非由程序算法闭环控制。

此外,行业对于汽车软件系统和算法的测试必须提上日程。作为车辆的一部分,软件和算法必须在经历千锤百炼的检测之后,才能展现出其稳定性和鲁棒性,进而保障汽车整体系统的安全性。

毕竟,代码是不可信任的,尤其是汽车。

       原文标题 : 智能汽车“软肋”:被忽视的电控安全

声明: 本文由入驻OFweek维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。
侵权投诉

下载OFweek,一手掌握高科技全行业资讯

还不是OFweek会员,马上注册
打开app,查看更多精彩资讯 >
  • 长按识别二维码
  • 进入OFweek阅读全文
长按图片进行保存