Uber的自动驾驶车辆上个月在美国发生撞人致死案件,笔者当时写了一篇报导“自动驾驶车们,请先跑完仿真再上路测试好吗?”;在文章发表之后,高通(Qualcomm)的人工智能(AI)研发业务开发负责人Rick Calle做出回应,问了我以下的问题:
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表示,对自驾车开发者来说有一个坏消息是,尽管累积了数十亿英哩的模拟驾驶里程,也不一定能涵盖自驾车可能遭遇的所谓“极端案例”或“边缘案例”。
在过去几年,深度学习芯片供货商耗费大量资源,宣传深度学习算法可能实现全自动驾驶系统,这种算法可能让自驾车发展出类似人类的能力,能在不需要知道每一种可能情况的前提下识别不同图形。
依赖深度学习的自动驾驶系统能被训练,发展出类似人类的能力(来源:Drive Safely)
不过来自反面的声音是,当机器学习或深度学习系统遭遇以往未见过的事物──被称为长尾(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也质疑所谓的“红色紧急按钮”是否实际可行?他解释,这种按钮能快速启动所谓的自驾车隔离机制,实际上有些设计真的是一个大尺寸的红色按钮。
两种不同的“红色紧急按钮”机制(来源:Phil Koopman)
上图是两种不同的紧急隔离机制设计;Koopman解释,左边的那种:“驾驶员的控制是透过自动驾驶软件,但如果自动驾驶软件有故障,可能会忽略驾驶员的控制;”换句话说:“在自驾车计算机上添加紧急控制按钮并不能保证系统安全,因为系统可能会忽略该按钮。”
至于右边的第二种设计,Koopman表示:“我们已经先假设自动驾驶软件会出现故障,所以我们可确保驾驶员拥有一个独立的途径,可透过某个开关来控制车辆;”他指出:“紧急控制按钮强迫系统接受驾驶员的控制,所以无论自驾车软件尝试做什么,都不会造成妨碍。”
以第二种设计案例来看,“如果开关设计是依据适当的ISO 26262 ASIL标准,在隔离机制方面就会是安全的;”Koopman表示:“要注意的是该设计的重点,是一旦红色紧急按钮被启动后,让任何自动驾驶系统的错误都不可能凌驾于人类安全驾驶员。”
如果Uber事故的悲剧有带给我们任何教训,就是消费者、产业界与主管机关都应该停止简单的争论,我们确保道路安全的唯一方法,是把人类排除在等式之外。我们更应该关心的是,让自动驾驶车辆能安全地与行人与其他人类驾驶车辆共存之前,还有多少工作要做。
编译:Judith Cheng
本文授权编译自EE Times,版权所有,谢绝转载