接续前文： 技术能否完全让自驾车事故悲剧不再发生？（上）
自动驾驶系统带给汽车业者的最大冲击，就是软件内容不断膨胀；软件开发商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事故的悲剧有带给我们任何教训，就是消费者、产业界与主管机关都应该停止简单的争论，我们确保道路安全的唯一方法，是把人类排除在等式之外。我们更应该关心的是，让自动驾驶车辆能安全地与行人与其他人类驾驶车辆共存之前，还有多少工作要做。
（原文发表于Aspencore旗下EDN姐妹媒体EETimes，原文Uber’s First Tragedy Likely Not the Last，Judith Cheng编译）
最前沿的电子设计资讯
