美国国家运输安全委员会(National Transportation Safety Board，NTSB)针对Uber自动驾驶测试车辆在美国亚利桑那州(Arizona)发生的撞人致死事故初步调查报告，在关于Uber自驾车究竟出了什么问题上面提供了我们一些深入观点，也揭露了几个令人惊讶的事实。
其中最令人惊讶的，是Uber决定将该Volvo制造测试车辆出厂配备的先进辅助驾驶(ADAS)功能停用，包括自动紧急剎车(AEB)；对此技术顾问机构VSI Labs创办人Phil Magney接受EE Times访问时表示：“这可能是自动驾驶出租车开发过程的例行工作，因为你不会希望原厂的ADAS系统与Uber的自驾车堆栈(AV stack)发生冲突。”
但让笔者与其他人感到困惑的是，为何Uber在公开道路上进行测试时也把自己的AEB功能给关了？当然，这是假设Uber的自驾车堆栈具备能正常运作的AEB。根据NTSB的报告，Uber声称其“开发中的自动驾驶系统若发生故障时，是仰赖专注的操作人员出手干预，让系统得以在测试过程中适当运作。”
而仔细阅读NTSB的初步调查报告，揭露了两个问题：其一是Uber自驾车软件堆栈的不成熟，另一个则是Uber在打造其自驾车测试平台时缺乏安全策略。
首先是Uber自驾车软件堆栈部份，我们会说它“不成熟”，是因为其传感器似乎有太多误报状况让Uber困扰，甚至达到该公司更信任人类驾驶员而非自家自驾车的程度。Uber在接受调查过程中对NTSB表示：“紧急剎车功能在车辆被计算机控制时无法作用，以降低车辆出现不稳定行为的可能性；车辆是仰赖随车操作员保持专注并采取行动。”
市场研究机构The Linley Group资深分析师Mike Demler怀疑，Uber的传感器融合，更精准地说是他们自己开发的软件“坏掉了”。但大家都想从NTSB报告中找到的关键信息，是从Uber自动驾驶系统取得的数据。
在NTSB的报告中写道：“…在车辆以时速43英哩行驶时，该系统是在发生撞击前大约6秒钟记录到雷达与光达(LiDAR)发现行人；当车辆与行人的路径会合，自动驾驶系统软件先将行人归类为未知物体、车辆，然后是未来行进路径有不同预期的自行车。在撞击发生前1.3秒，自动驾驶系统决定需要采取紧急剎车操作以减轻撞击。”
文章最上方NTSB提供的大图显示Uber自动驾驶系统数据在撞击前约1.3秒的数据重现，当时系统决定需要采取紧急剎车操作，以减轻撞击。图中的黄线标示了车辆前方距离(公尺)，橘色线是对向车道中线；紫色的区块则是车辆行驶路径，其中的绿色线是车道中线。
这种自驾车的片刻迟疑──从发现行人的撞击前6秒，到做出决策的撞击前1.3秒──在车辆紧急情况中几乎是永远；问题在于为何Uber自驾车会等那么久才反应。对此Demler认为：“那里有某个东西，所以该软件应该在6秒内采取行动避免撞到它。”
平心而论，考虑到机器学习的非确定性(non-deterministic)本质，该测试车辆的犹豫是一种机器人意识。如Magney所言：“当传感器侦测到某个物体时，会有一段分类的辛苦程序；一个牵着上面有一堆袋子的脚踏车的人…这个场景可能是该系统未受过训练的。”
此外他指出：“也会有关于物体在车辆(最初)轨迹之外的问题；尽管如此，计算机并非一开始就将该物体视为威胁，因为预测运动并不准确。”
Uber的软件绝对有技术问题；虽然所有车子里的软件毛病都让人不安，更深一层的问题是Uber对于在公开道路上行驶未臻完美的自动驾驶车辆，是如何严肃地负起责任？还有Uber的自驾车测试平台采取了什么样的特定安全措施？
Demler表示，Uber软件缺乏恰当的传感器融合，是“技术性问题”；但Uber因为软件容易出现误报而关闭AEB，就是“管理失责”。
在这里值得注意的事实，并非Uber的自驾车不够完美；美国卡内基美隆大学(Carnegie Mellon University)教授、安全专家Phil Koopman在一篇刊登于EE Times的博客文章中就写道：“其实是一辆‘测试车’撞死了Elaine Herzberg——而不是完全自动驾驶车酿祸。”
让我们面对现实：我们都知道自动驾驶技术不成熟，但这并不代表我们不关心测试车辆的安全。我们应该要问Uber，该公司还要走多长一段路才能确保其测试自驾车的安全？没有任何人应该为了让机器人世界安全而牺牲。
在NTSB的初步调查报告出炉后，Koopman重申：“找出自动驾驶技术出了什么问题、吸取教训并改善安全性非常重要；这起事故真的不是自动驾驶技术的失败，而是自驾车在公开道路上测试的安全失误。”
简而言之，他认为：“指责任何一种自动驾驶技术故障是造成死亡事故原因，都是误解；事故的发生是因为自驾车测是的安全方案出错；”他补充指出：“考虑一下，Uber知道自动驾驶技术不可靠，因为还在开发阶段。所以为何自动驾驶技术故障应该令人惊讶？故障是可预期的；这也是为何他们有随车安全驾驶员。”
美国卡内基美隆大学(Carnegie Mellon University)教授、安全专家Phil Koopman强烈支持，每一家自驾车业者若要在毫无戒心的大众面前进行车辆测试，都应该在取得地方政府许可之前先做好安全措施；他主张，自驾车业者应该要提出“经结构化的书面论证，由证据支持，证明系统在预期的使用上具备可接受的安全性。”
不过到目前为止，美国并没有哪一个州或是城市，要求自驾车业者必须做到以上的安全案例(safety case)。当然，Uber自动驾驶测试车在发生撞人致死事故之后不得不停止在所有地方的测试，甚至在日前关闭了在亚利桑那州(Arizona)的自驾车营运据点，并裁撤了300名驾驶员；但这恐怕是“船到江心补漏迟”。
Koopman表示，对有志投入自驾车事业者来说，书面安全案例不需要负担繁重法律责任，也不会泄露技术机密，厂商应该可以这样表示：“以下是安全理由1，还有关于1的证据。”
虽然Uber决定把测试车辆上的自动紧急剎车(AEB)功能关闭，只靠“安全驾驶员”来控制剎车听起来很轻率，甚至Uber还决定将提醒人类驾驶员在紧急状况时采取控制行动的警报系统静音…他们为什么这么做？
Koopman在4月初于美国匹兹堡(Pittsburgh)举行的宾州自动车辆高峰会(Pennsylvania Automated Vehicle Summit)上指出：“必须要有一位安全驾驶员，不能裁撤；”他解释，最低限度安全主管机关必须要被告知该安全驾驶如何接受训练，还有自驾车业者打算怎么确保安全驾驶员是保持警觉的，以及自驾车业者将如何监测安全驾驶员在路上的表现。
以Uber的事故为例，问题并不在于讨论Level 3自动驾驶车辆时许多专家会提到的、在紧急情况时机器与人类驾驶员换手的根本性难题；如果Uber对NTSB的声明是真实的，令人担忧的换手根本不是问题，因为Uber“开发中”的自动驾驶系统如遇到故障，是仰赖专注的操作员来采取适当的行动。
技术顾问机构VSI Labs创办人Phil Magney表示：“你可能会想，Uber会向那些测试驾驶员简报，当某些特殊的情况发生时需要额外注意；也许他们有这么做，只是我们不知道。”
而Magney指出，对于Uber停用AEB功能，最善意的解释可能是：“Uber关闭AEB是为了测试系统的其他元素，或许该AEB功能过度敏感并导致太多的误报…我可以想见他们可能会测试关联性功能的哪些地方，而且不想让紧急剎车系统干预；也许是为了检察算法如何处理一般任务，像是非紧急性情况下的避开障碍物。”
Koopman同意以上说法；他表示，Uber停用AEB“在大众认知是坏心眼，但并不一定是工程性错误。”他进一步解释：“如果其余的测试策略都有被正确设计与实施，这就不一定是个问题；如果我可以选，我大概会希望该功能是开启的，但我可以想象将之关闭是一种可接受设计选项的情况。”
他总结指出：“我的观点并不是要判定关闭自动紧急剎车是好或坏，这个问题的答案应该要取决于整体安全方案。”
或许是这样，但如同The Linley Group资深分析师Mike Demler所言，对我们大多数人来说，事情发生经过像是：“在马路上的Uber自动行驶，但确保安全的机制却被关闭了；”这不是坏心眼是什么？
尽管如此，更重要的问题是：“为何安全驾驶员没有避免撞击？”Koopman表示：“到目前为止我们没有具体的理由真正归咎该驾驶员；不过被描述的因素指明，仔细检视Uber道路测试方案与策略真的很重要。”
毕竟安全驾驶员已经负责许多工作；如NTSB报告所指：“该操作员负责监测显示于车辆仪表板中央接口上的诊断信息，并且标记值得随后审查的事件。”
而Koopman指出，在提出安全性论据时，随车操作员可以举出实例，像是列出“驾驶人的受训以及合格证明，车辆安装的实时驾驶员警觉性监测系统，以及分享驾驶员表现数据的审查信息；”他们也可以提供一套系统，具备足够的复原余裕，不至于让人类驾驶员撞上突然窜出的行人与自行车骑手。
当然，我们现在还是不知道Uber是否采取了任何安全措施，因为该公司并没有被要求提出安全案例。
编译：Judith Cheng
本文授权编译自EE Times，版权所有，谢绝转载
关注最前沿的电子设计资讯，请关注“电子工程专辑微信公众号”。
