我们能否让无人驾驶汽车事故悲剧发生机率降低？

 

Uber 撞人事件是第一场悲剧，我们该如何让它变成最后一场？我非常确定他们也用了仿真软件，但大家是否仿真了传感器故障的情况，因为距离使得光达（Lidar）采样稀疏的效应，还有其他不可预测的事件？

 

Calle 的问题指出了测试无人驾驶汽车绝非易事，要验证无人驾驶汽车不只是能运作，各种功能还必须安全运作，需要前所未有的工程严谨度；测试人员不仅得确定需要模拟的内容，也要确保模拟过程使用了高保真度的感测数据。接着必须拟定测试计划，以便为车辆供货商提供足够可证明的安全性能指针。

 

不过，在了解模拟/ 测试方法的细节之前，知道一件事情很重要──我们今日所知的「无人驾驶」仍然不成熟。

 

美国卡内基梅隆大学（Carnegie Mellon University）教授Philip Koopman 在最新的一篇博客文章中写道，在Uber 事故导致行人Elaine Herzberg 身亡的并非真正的无人驾驶汽车，而是一辆仍在开发阶段的“未经实证的测试车”，还有「应该要确保技术故障不会导致伤害的那个安全驾驶」。

 

让我们一起想想…过去一年半以来，科技业者（还有媒体）忙着促成全无人驾驶汽车的即将实现，却漠视了无数挥之不去的、关于无人驾驶的“未知”；这里的“未知”，我指的是无人驾驶汽车所衍生出的、科技产业几乎还未开始处理的议题，更不用说提出因应策略。

 

我们询问过数个产业界消息来源──从算法开发者、测试专家，到嵌入式系统软件工程师，他们仍认为开发「安全的」 无人驾驶汽车是一个不确定的议题或挑战，虽然他们的回答各异，却都坦承无人驾驶汽车还有很多议题，有待来自科技与汽车产业的回答。

 

 

无人驾驶汽车技术开发商DeepScale 首席执行官Forrest Iandola 在谈到Uber 事故时表示，除非Uber 公布行车纪录仪以外的数据，包括车上的雷达与摄影机在事故发生时所看到的，否则外界人士可能永远不会知道事故发生原因：“我们需要透明的信息，不然很难知道他们的感知系统、动作规划或是地图绘制等功能究竟哪里出错。”

 

DeepSale 是一家成立于2015 年的初创公司，专门为先进驾驶辅助系统( ADAS ) 与无人驾驶汽车开发深度学习感知软件；根据该公司已经学到的经验， Iandola 解释，大多数为无人驾驶汽车设计的感知系统是产业界与学术界“精心打造”，举例来说，光达已经可以清楚识别3D目标物的形状，同时无人驾驶汽车的“语义”（semantic）感知在物体分类方面也有所改善。

 

不过仍缺乏的，是“预测性感知”（predictive perception）； Iandola 指出：「预测性感知技术的研发几乎还没开始。」

 

举例来说，如果无人驾驶汽车不能预测某目标物在5秒后的可能位置，就不能决定是否该煞车或转向，甚至是在看到该目标物体后。「在运动规划与预测性信息之间需要一个标准接口，」 Iandola 表示，「如果这个问题没有解决，我得说要实现Level 4 无人驾驶汽车真的很困难。」

 

 

在公开道路上测试无人驾驶汽车之前的模拟显然非常重要，但更重要的是实际上如何模拟。安全无人驾驶汽车系统开发商Edge Case Research 联合创始人兼首席执行官Michael Wagner 表示，对无人驾驶汽车开发者来说有一个坏消息是，尽管累积了数十亿英哩的模拟驾驶里程，也不一定能涵盖无人驾驶汽车可能遭遇的所谓“极端案例”或“边缘案例”。

 

在过去几年，深度学习芯片供货商耗费大量资源，宣传深度学习算法可能实现全自动驾驶系统，这种算法可能让无人驾驶汽车发展出类似人类的能力，能在不需要知道每一种可能情况的前提下识别不同图形。

不过来自反面的声音是，当机器学习或深度学习系统遭遇以往未见过的事物──被称为长尾（long tail）或离群值（outlier）──会被“吓到”；而人类驾驶在面临实在异常的状况时，至少会有的反应是觉得奇怪，他们知道在某种程度上需要有所反应，而机器则可能不会记录极端异常的情况，会继续往前走。

 

Wagner 表示， Edge Case Research 专注于建立这样的极端情况，以纳入仿真软件平台；他坦承一切还在早期开发阶段，该公司的平台代号为“全像”（Hologram），目标是将实体车辆所行驶过的每一英哩转化为数百万计的可能场景，尽可能快速且安全地根除“未知的未知”。

 

要为无人驾驶汽车建立这种“极端案例”并不简单； Wagner 指出，在欧洲有一个名为Pegasus 的项目利用了一种数据库方法来确保无人驾驶安全，但挑战在于该项目的某部份场景，可能对神经网络来说不一定重要。

 

Wagner表示，也就是说，我们其实并不知道神经网络会发现什么难题或不容易处理的情况，更别说为何神经网络会有那样的行为模式：“随机性对于建立异常案例非常重要，我们利用实际的场景，在影像上做不少变化，然后在我们的Hologram 平台上进行细微修改。”

 

他将Hologram 形容为一个试验专案：「我们正在向投资者推销这个平台，以扩大它的规模。」

 

自动驾驶系统带给汽车业者的最大冲击，就是软件内容不断膨胀；软件开发商Green Hills Software 汽车业务开发总监Chuck Brokish 在接受EE Times 采访时就表示：「链接库变得太庞大…拖慢了安全软件评估程序。」

 

今日的车用芯片领导厂商声称其车用SoC 或MCU 即将取得ASIL (Automotive Safety Integrity Level)-D 安全性认证，而因为该认证是协助定义符合ISO 26262 标准的必备安全性要求，这是正面的发展，但ASIL – D 芯片上执行的软件呢？也同时取得了ASIL – D 认证吗？

 

对此Brokish 指出：「并没有，他们会说他们的软件是经过'质量控管'(quality-managed)，」他解释，这代表该类软件的安全性并没有经过单独验证或是认证。有数个产业团体包括SAE 、 ISO 等，正在努力为软件安全性开发“准则”，但Brokish 认为，还需要至少几年的时间一切才能底定。

 

 

考虑到Uber 无人驾驶汽车事故悲剧，政府主管机关应该要谨慎重新思考信任自驾车营运商安全性声明的现行策略；主管至少该期望无人驾驶汽车营运商提供证据，证明他们的实际道路测试方法足够安全。不过美国卡内基梅隆大学（Carnegie Mellon University）教授Philip Koopman 表示，在道路测试之前，他不会要求无人驾驶汽车完美证明其安全性。

 

他建议无人驾驶汽车营运商应该被要求报告其安全性案例，以结构化的书面声明形式，并有证据作为支持，证明其系统在使用意图上具备可接受的安全性；他并强调该保证测试无人驾驶汽车上配有一名安全驾驶员，不能撤销。

 

Koopman 在4 月初于美国匹兹堡（Pittsburgh）举行的宾州自动车辆高峰会(Pennsylvania Automated Vehicle Summit)上，发表了一场题为「确保无人驾驶汽车道路测试安全性」(Ensuring the Safety of On- Road Self -Driving Car Testing)的演说，主要是探讨「如何让无人驾驶汽车测试够安全」。

 

他强调：「这不是说模拟不重要，事实上我认为模拟相当重要；」不过他补充指出：「无论你做了多少模拟，到某个阶段你还是需要开到外面的实际道路，在那一天来临之前，你需要确认安全驾驶确实能保障测试系统的安全，甚至在无人驾驶汽车零部件出现仿真时未预期的错误时。」

 

Koopman 在演说中表示，驾驶员注意力不集中的状况在飞行员之间也很常见，所以一定要有一位副驾驶来担任备援；无人驾驶汽车营运商必须致力于妥善训练安全驾驶员，让这个人能保持专注，同时也需要实时监控该驾驶员的警觉性。

 

同样重要的，是以一种让安全驾驶员能及时反应的方法来设计无人驾驶汽车；他指出，无人驾驶汽车供货商应该要确保「无人驾驶汽车隔离机制实际可运作」；而Koopman 也质疑所谓的“红色紧急按钮”是否实际可行？他解释，这种按钮能快速启动所谓的无人驾驶汽车隔离机制，实际上有些设计真的是一个大尺寸的红色按钮。

上图是两种不同的紧急隔离机制设计； Koopman 解释，左边的那种：「驾驶员的控制是通过自动驾驶软件，但如果自动驾驶软件有故障，可能会忽略驾驶员的控制；」换句话说：「在无人驾驶汽车计算机上添加紧急控制按钮并不能保证系统安全，因为系统可能会忽略该按钮。」

 

至于右边的第二种设计， Koopman 表示：「我们已经先假设自动驾驶软件会出现故障，所以我们可确保驾驶员拥有一个独立的途径，可通过某个开关来控制车辆；」他指出：「紧急控制按钮强迫系统接受驾驶员的控制，所以无论无人驾驶汽车软件尝试做什么，都不会造成妨碍。」

 

以第二种设计案例来看，「如果开关设计是依据适当的ISO 26262 ASIL标准，在隔离机制方面就会是安全的；」Koopman 表示：「要注意的是该设计的重点，是一旦红色紧急按钮被启动后，让任何自动驾驶系统的错误都不可能凌驾于人类安全驾驶员。」

 

如果Uber 事故的悲剧有带给我们任何教训，就是消费者、产业界与主管机关都应该停止简单的争论，我们确保道路安全的唯一方法，是把人类排除在等式之外。我们更应该关心的是，让无人驾驶汽车能安全地与行人与其他人类驾驶车辆共存之前，还有多少工作要做。