结果显示，这只团队在4小时发现了561个关键安全故障，其中，百度Apollo 3.0和英伟达具体故障占比并未说明。
针对这一事件，百度在第一时间发表声明称，“非常重视测试发现的模块异常，将持续优化，Apollo自动驾驶系统的运行依赖于软硬件各模块的协同工作，从而完成自动驾驶的安全运行。在新型FI测试中，同样依托多模块的软硬件协同机制，从而避免风险的实际发生。”
从百度回应中可以看出，单纯的软件故障并不能使自动驾驶汽车发生一系统安全事故。
百度Apollo回应美专家安全故障评测，虚拟容器评测漏洞远不能导致自动驾驶汽车事故发生
除了百度回应外，单从这一事件本身在车端可行性而言，其实，存在很多讨论的地方。
通过论文可以了解到，该研究将Apollo的代码放到一个服务器上的虚拟容器（Docker）上进行测试，导致注入故障后无法解决。
这里我们需要知道一个前提条件就是，故障注入是针对系统的，而百度真实的系统是软硬件一体，Apollo代码运行于符合车规和功能安全的硬件上，即便注入故障也不会出现问题。
与此同时，在实际驾驶过程中，Apollo冗余系统一旦发现车速异常，就不会执行深踩油门的动作，也就不会产生类似追尾的风险。
另外，论文中人为修改自动驾驶的控制输出，造成猛踩油门，而这情况在真实的安全硬件上不会发生。
百度Apollo回应美专家安全故障评测，虚拟容器评测漏洞远不能导致自动驾驶汽车事故发生
按照我们实际的开车经验，大部分情况下，即便车往前窜了一下，也不至于撞到前面的车。
在这篇论文中可以找到一个极端的CASE，即本车以安全的车距在跟随前面的车，在车速被改、向前加速一下的同时，假如恰好有一辆车从旁边车道并线过来，安全车距就会突然变短，这时候才会撞车。
不过，这样的事故，全责在变道车。
对此，百度相关人员也给予了同样的解释，“因为真实的硬件上，这部分代码跑在ASIL-D级安全的MCU上，这种安全MCU里面有两个处理器，试行同样的运算，相关校验，它把一个处理器的内存改掉，让它计算错误，这就会和另一个处理器的值不一样，立刻就发现了，根本不会输出。”
自动驾驶相关安全领域专家也对此事件做出点评，他们认为，“故障注入”研究方法是在一些位置植入故障，如果场景导致事故，则该植入场景算作研究中的一个‘Fault’。”
也就是说，如果测试中将刹车破坏，从而导致事故，则刹车失灵是一个“Fault”。
其实，今年7月，美国伊利诺伊大学香槟分校研究人员发表题为《ML-based Fault Injection for Autonomous Vehicles: A Case for Bayesian Fault Injection》的论文，根据相关表述，研究人员对百度Apollo、英伟达进行了两种FI测试。
其中，在传统故障注入（FI）下，Apollo代码和参数没有出现任何问题，表现稳健。
在这起自动驾驶故障评估事件中，我们看到美国伊利诺伊大学香槟分校研究人员是想通过故障评估的方法来验证自动驾驶系统的安全性，但由于评测有过多的人为修改以及模拟测试结果导致其公众误读。
诚然，评测机构的权益与企业的权益都应该得到尊重，而辨别其中的责任，我们更需要从实际出发，理性的看待自动驾驶汽车出现的问题。
以下为百度Apollo完整回应：
我们关注到近期伊利诺伊大学香槟分校研究人员对Apollo开放平台的关注和使用，我们正与对方取得联系，了解更多信息。
根据论文表述，研究人员对Apollo进行两种FI测试，在传统故障注入（FI）下，Apollo代码和参数没有出现任何问题，表现稳健。感谢该校研究人员对Apollo平台的认可。而新型的FI是使用故意更改代码和参数的方式，引发严重错误或警告性错误，可帮助自动驾驶更好地发现安全风险。
Apollo自动驾驶系统的运行依赖于软硬件各模块协同工作，从而完成自动驾驶安全运行。对该分校在新型FI测试中出现的模块故障，我们有多模块软硬件协同机制，来避免风险实际发生。在新型FI测试中，会人为地把代码里面输出的点踩油门控制信号修改成深踩油门。而在实际过程中，Apollo冗余系统一旦发现车速异常，就不会执行深踩油门动作，也就不会产生类似追尾风险。
但即便多模块协同、软硬件冗余能避免安全风险产生，我们也还是非常重视FI发现的模块异常，并持续优化。
就开源平台本身而言，我们高兴地看到平台给大家的研发带来了便利和可能性。通过开源代码，我们一起去发现问题，解决问题。通常在一项技术高速发展期，如Apollo开源系统，在全球开发者帮助下，会比封闭系统都更安全，这也是我们开源的目的与意义所在。
Apollo每天都在持续迭代，向更安全、更可靠、更完备上进步。Apollo也希望集大家力量，共同推进人类梦想进步。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
