接續前文: 我們能否讓自駕車事故悲劇不再發生?(上)  

自動駕駛系統帶給汽車業者的最大衝擊,就是軟體內容不斷膨脹;軟體開發商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也質疑所謂的「紅色緊急按鈕」是否實際可行?他解釋,這種按鈕能快速啟動所謂的自駕車隔離機制,實際上有些設計真的是一個大尺寸的紅色按鈕。

20180410_AV_NT02P2

兩種不同的「紅色緊急按鈕」機制
(來源:Phil Koopman)

上圖是兩種不同的緊急隔離機制設計;Koopman解釋,左邊的那種:「駕駛員的控制是透過自動駕駛軟體,但如果自動駕駛軟體有故障,可能會忽略駕駛員的控制;」換句話說:「在自駕車電腦上添加緊急控制按鈕並不能保證系統安全,因為系統可能會忽略該按鈕。」

至於右邊的第二種設計,Koopman表示:「我們已經先假設自動駕駛軟體會出現故障,所以我們可確保駕駛員擁有一個獨立的途徑,可透過某個開關來控制車輛;」他指出:「緊急控制按鈕強迫系統接受駕駛員的控制,所以無論自駕車軟體嘗試做什麼,都不會造成妨礙。」

以第二種設計案例來看,「如果開關設計是依據適當的ISO 26262 ASIL標準,在隔離機制方面就會是安全的;」Koopman表示:「要注意的是該設計的重點,是一旦紅色緊急按鈕被啟動後,讓任何自動駕駛系統的錯誤都不可能凌駕於人類安全駕駛員。」

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

編譯:Judith Cheng

(參考原文: Uber’s First Tragedy Likely Not the Last,by Junko Yoshida)