百度Apollo回应美专家安全故障评测,虚拟容器评测漏洞远不能导致自动驾驶事故

  • 时间:
  • 浏览:1
  • 来源:大发排列3

近日,伊利诺伊大学香槟分校的有5个研究团队新开发了一种针对自动驾驶的故障评估技术,亲戚亲戚朋友 首先对百度Apollo 3.0和英伟达专有自动驾驶系统DriveAV进行了一次软件故障评估。

结果显示,这只团队在4小时发现了56有5个关键安全故障,其中,百度Apollo 3.0和英伟达具体故障占比并未说明。

针对这些 事件,百度在第一时间表态称,“非常重视测试发现的模块异常,将持续优化,Apollo自动驾驶系统的运行依赖于软硬件各模块的协同工作,从而完成自动驾驶的安全运行。在新型FI测试中,同样依托多模块的软硬件协同机制,从而避免风险的实际存在。”

从百度表态中时要看出,单纯的软件故障并不到使自动驾驶汽车存在一系统安全事故。

除了百度表态外,单从这些 事件一种在车端可行性而言,实在,存在什么都有讨论的地方。

通过论文时要了解到,该研究将Apollo的代码里装 有5个服务器上的虚拟容器(Docker)上进行测试,意味分析注入故障后无法避免。

这里亲戚亲戚亲戚朋友 时要知道有5个前提条件回会,故障注入是针对系统的,而百度真实的系统是软硬件一体,Apollo代码运行于符合车规和功能安全的硬件上,即便注入故障之回会出先间题报告 。

与此一同,在实际驾驶过程中,Apollo冗余系统一旦发现车速异常,就回会执行深踩油门的动作,也就回会产生这类追尾的风险。

另外,论文中人为修改自动驾驶的控制输出,造成猛踩油门,而这情形在真实的安全硬件上回会存在。

按照亲戚亲戚亲戚朋友 实际的开车经验,大部分情形下,即便车往前窜了一下,回会至于撞到前面的车。

在这篇论文中时要找到有5个极端的CASE,即本车以安全的车距在跟随前面的车,在车速被改、向前加速一下的一同,回会恰好有一百公里车从旁边车道并线过来,安全车距就会总爱变短,这完后 才会撞车。

不过,完后 的事故,全责在变道车。

对此,百度相关人员也给予了同样的解释,“是意味分析真实的硬件上,这部分代码跑在ASIL-D级安全的MCU上,这些 安全MCU里面有有5个避免器,试行同样的运算,相关校验,它把有5个避免器的内存改掉,让它计算错误,这就会和完后 避免器的值不一样,立刻就发现了,根本回会输出。”

自动驾驶相关安全领域专家也对此事件做出点评,亲戚亲戚朋友 认为,“故障注入”研究依据是在回会 位置植入故障,是意味分析场景意味分析事故,则该植入场景算作研究中的有5个‘Fault’。”

也回会说,是意味分析测试中将刹车破坏,从而意味分析事故,则刹车失灵是有5个“Fault”。

实在,今年7月,美国伊利诺伊大学香槟分校研究人员发表题为《ML-based Fault Injection for Autonomous Vehicles: A Case for Bayesian Fault Injection》的论文,根据相关表述,研究人员对百度Apollo、英伟达进行了一种FI测试。

其中,在传统故障注入(FI)下,Apollo代码和参数不出出先任何间题报告 ,表现稳健。

在这起自动驾驶故障评估事件中,亲戚亲戚亲戚朋友 看得人美国伊利诺伊大学香槟分校研究人员是想通过故障评估的依据来验证自动驾驶系统的安全性,回会意味分析评测有回会 的人为修改以及模拟测试结果意味分析其公众误读。

诚然,评测机构的权益与企业的权益都应该得到尊重,而辨别其中的责任,亲戚亲戚亲戚朋友 更时要从实际出发,理性的看待自动驾驶汽车出先的间题报告 。

以下为百度Apollo完整性表态: