自動駕駛系統(tǒng)帶給汽車業(yè)者的最大沖擊，就是軟件內容不斷膨脹；軟件開發(fā)商GreenHillsSoftware汽車業(yè)務開發(fā)總監(jiān)ChuckBrokish在接受EETimes采訪時就表示：「鏈接庫變得太龐大…拖慢了安全軟件評估程序?！?/p>

今日的車用芯片領導廠商聲稱其車用SoC或MCU即將取得ASIL(AutomotiveSafetyIntegrityLevel)-D安全性認證，而因為該認證是協(xié)助定義符合ISO26262標準的必備安全性要求，這是正面的發(fā)展，但ASIL-D芯片上執(zhí)行的軟件呢？也同時取得了ASIL-D認證嗎？

對此Brokish指出：「并沒有，他們會說他們的軟件是經過『質量控管』(quality-managed)，」他解釋，這代表該類軟件的安全性并沒有經過單獨驗證或是認證。有數(shù)個產業(yè)團體包括SAE、ISO等，正在努力為軟件安全性開發(fā)「準則」，但Brokish認為，還需要至少幾年的時間一切才能底定。

「緊急紅色按鈕」可行嗎？

考慮到Uber自駕車事故悲劇，政府主管機關應該要謹慎重新思考信任自駕車營運商安全性聲明的現(xiàn)行策略；主管至少該期望自駕車營運商提供證據(jù)，證明他們的實際道路測試方法足夠安全。不過美國卡內基美隆大學(CarnegieMellonUniversity)教授PhilipKoopman表示，在道路測試之前，他不會要求自駕車完美證明其安全性。

他建議自駕車營運商應該被要求報告其安全性案例，「以結構化的書面聲明形式，并有證據(jù)作為支持，證明其系統(tǒng)在使用意圖上具備可接受的安全性；」他并強調該保證測試自駕車上配有一名安全駕駛，不能撤銷。

Koopman在4月初于美國匹茲堡(Pittsburgh)舉行的賓州自動車輛高峰會(PennsylvaniaAutomatedVehicleSummit)上，發(fā)表了一場題為「確保自駕車道路測試安全性」(EnsuringtheSafetyofOn-RoadSelf-DrivingCarTesting)的演說，主要是探討「如何讓自駕車測試夠安全」。

他強調：「這不是說模擬不重要，事實上我認為模擬相當重要；」不過他補充指出：「無論你做了多少模擬，到某個階段你還是需要開到外面的實際道路，在那一天來臨之前，你需要確認安全駕駛確實能保障測試系統(tǒng)的安全，甚至在自駕車零組件出現(xiàn)仿真時未預期的錯誤時?！?/p>

Koopman在演說中表示，駕駛員注意力不集中的狀況在飛行員之間也很常見，所以一定要有一位副駕駛來擔任備援；自駕車營運商必須致力于妥善訓練安全駕駛員，讓這個人能保持專注，同時也需要實時監(jiān)控該駕駛員的警覺性。

同樣重要的，是以一種讓安全駕駛員能及時反應的方法來設計自駕車；他指出，自駕車供貨商應該要確?！缸择{車隔離機制實際可運作」；而Koopman也質疑所謂的「紅色緊急按鈕」是否實際可行？他解釋，這種按鈕能快速啟動所謂的自駕車隔離機制，實際上有些設計真的是一個大尺寸的紅色按鈕。

兩種不同的「紅色緊急按鈕」機制（來源：PhilKoopman）

上圖是兩種不同的緊急隔離機制設計；Koopman解釋，左邊的那種：「駕駛員的控制是透過自動駕駛軟件，但如果自動駕駛軟件有故障，可能會忽略駕駛員的控制；」換句話說：「在自駕車計算機上添加緊急控制按鈕并不能保證系統(tǒng)安全，因為系統(tǒng)可能會忽略該按鈕?！?/p>

至于右邊的第二種設計，Koopman表示：「我們已經先假設自動駕駛軟件會出現(xiàn)故障，所以我們可確保駕駛員擁有一個獨立的途徑，可透過某個開關來控制車輛；」他指出：「緊急控制按鈕強迫系統(tǒng)接受駕駛員的控制，所以無論自駕車軟件嘗試做什么，都不會造成妨礙?！?/p>

以第二種設計案例來看，「如果開關設計是依據(jù)適當?shù)腎SO26262ASIL標準，在隔離機制方面就會是安全的；」Koopman表示：「要注意的是該設計的重點，是一旦紅色緊急按鈕被啟動后，讓任何自動駕駛系統(tǒng)的錯誤都不可能凌駕于人類安全駕駛員?！?/p>

如果Uber事故的悲劇有帶給我們任何教訓，就是消費者、產業(yè)界與主管機關都應該停止簡單的爭論，我們確保道路安全的唯一方法，是把人類排除在等式之外。我們更應該關心的是，讓自動駕駛車輛能安全地與行人與其他人類駕駛車輛共存之前，還有多少工作要做。