如以色列新創公司Foretellix執行長暨共同創辦人Ziv Binyamini所言,SoC與AV都像是在一個「黑盒子」裡,本質上「不容易找到隱藏在你想像不到的地方的錯誤。」

SoC的測試與驗證有兩個重要指標:一是「程式碼覆蓋率」(code coverage),能顯示激勵(stimulus)對程式碼的測試程度;還有「功能覆蓋率」(functional coverage),是一種讓使用者編寫特定儀控邏輯(instrumentation logic)來監測激勵對不同功能覆蓋程度的方法。而Foretellix認為,類似的覆蓋率導向原則應該也要應用在車廠對AV進行安全性測試的流程中。

今日,包括科技業者與車廠打造的車輛,爭相在模擬軟體、測試車道以及公開道路上進行數百萬英哩行駛里程的測試;例如上個月Waymo宣佈,該公司的自駕車道路測試已經超過1,000萬英哩,在模擬軟體上累積的測試也達到了100萬英哩。

但問題在於:有誰知道像是Waymo、Uber、Cruise還有Argo AI這些公司實際上在測試什麼?他們如何衡量測試結果?他們的自駕車所經歷的測試場景是什麼樣的?

Ziv Binyamini
Ziv Binyamini

根據Foretellix的Binyamini觀察,現今各家自駕車業者的測試里程數競賽──為了要證明其產品安全性──缺乏「一種可量化的方法,來衡量自駕車需要執行(覆蓋)多少測試場景,才能證明其安全性;」此外他們還缺乏「能提供嚴謹、自動化方法發現未知風險場景,並將之轉為已知的工具。」

這正是Foretellix看到的機會,該公司是由具備豐富EDA產業資歷的驗證專家所組成,他們正將自己在IC設計領域的專長運用於自駕車設計。

Binyamini在接受EE Times採訪時表示,EDA產業在數十年前為SoC設計開發了高階硬體描述/硬體驗證語言SystemVerilog,Foretellix則是正在為AV設計工程師開發一種「可衡量場景描述語言」(Measurable Scenario Description Language,M-SDL);目前有幾家美國與歐洲的車廠正在試用M-SDL,預計在將來自業界的回饋彙整於該語言後,於夏季過後正式發表。

而Binyamini強調,M-SDL不是專屬語言,「將在GitHub上開放;」此外Foretellix承諾M-SDL可為自駕車測試結果──無論是在模擬軟體、測試場或是公開道路上進行的測試──提供「統一指標,我們還注入了隨機測試,以發現還有那些需要被測試的場景。」

20190815_Foretellix_NT01P1

覆蓋率導向(coverage-driven)的驗證
(來源:Foretellix)

不過市場研究機構The Linley Group資深分析師Mike Demler指出,Foretellix並不是在打造自駕車系統的驗證工具,而是提出「一種覆蓋率分析工具以及覆蓋率導向驗證方法。」

雖然Demler也坦承「覆蓋率導向驗證」的概念是來自EDA,但他強調:「覆蓋率是一種檢查驗證計畫的工具,本身並非驗證工具;覆蓋率工具能檢查覆蓋你的測試平台是否覆蓋所有可能的錯誤,或是達到一個滿足特定簽核(sign-off)標準的數量。」

因此在Demler看來,Foretellix拿M-SDL對比SystemVerilog,是「有點誇大;前者看來比較像是一種測試計畫檢查器(test plan checker)。」

將IC設計經驗運用於自駕車設計

儘管如此,從Foretellix的創辦人背景可以看出,這家公司特別想強調的是,他們要將在半導體設計領域累積的豐富專業經驗帶到汽車產業。Binyamini認為,任何人經歷過晶片設計不斷複雜化的年代,一定會覺得自駕車設計的演進過程很熟悉:「那些問題都是晶片產業在1990年代遭遇過的。」

當英特爾(Intel)正在開發Pentium Pro處理器時,Binyamini是該P6架構處理器設計專案團隊中的一個設計自動化工程師;而由於該P6架構處理器設計案是第一款採用x86超級流水線(super pipeline),以及亂序推測執行的機器,「相當複雜,需要新的驗證解決方案因應複雜性。」

在該款P6處理器問世前,英特爾的早期處理器曾面臨「Pentium bug」危機,即浮點架構缺陷;這種缺陷於1994年被美國林奇堡學院(Lynchberg College)的一個教授發現,當時EE Times也曾有過報導。英特爾在1994年12月召回該款有缺陷的處理器,耗費的成本高達5億美元;這場意外事件讓電子產業意識到,幾乎不可能發現複雜處理器中的所有缺陷與問題。

1997年,Binyamini加入一家在1995年由領導級VLSI驗證專家Yoav Hollander創辦的新公司Verisity;該公司被視為全球第一家驗證技術供應商,以覆蓋率導向方法論為基礎提供VLSI驗證工具套件。當時Verisity告訴半導體產業,覆蓋率導向驗證是「解決複雜晶片設計的唯一方法」,而Hollander在Verisity打造了「e」驗證語言,後來成為業界標準(IEEE 1647)。

Verisity在2005年被Cadence收購,Binyamini與Hollander也加入了後者,並在後來的十年之間成為該公司驗證業務團隊領導人;他們在2015年離開Cadence,並於2018年共同創辦了Foretellix,試圖解決自駕車產業的設計難題。

在IC領域,SoC設計錯誤可能會導致成本驚人的晶片重新設計,而如果晶片設計工程師整體精力有一半投注在設計上,另一半就是在驗證流程,這部份的工作會是晶片的成敗關鍵。在自駕車領域,任何設計上的缺陷則是可能導致人命損失。然而Foretellix認為,自駕車產業目前仍停留在「測試里程數」的競賽,而非安全性測試與驗證所需的「覆蓋率品質」。

高度自動化車輛中的系統已經夠複雜,若要添加一些環境與行為因素(例如惡劣天氣、路況,以及其他車輛切入切出車道等等)的測試場景,測試方案會變得越來越笨重;而Foretellix聲稱,其工具能克服這些挑戰,藉由M-SDL提供「可衡量的安全性」,並以自動化方法產生「不同場景組合」。該工具還能產生隨機建立組合場景,監測、檢查與追蹤場景覆蓋率。

20190815_Foretellix_NT01P2

Foretellix的工具能處理許多衍生測試場景。
(來源:Foretellix)

Foretellix的工具能用在哪些地方?

針對Foretellix的工具,自駕車技術顧問機構VSI Labs創辦人暨首席顧問Phil Magney接受EE Times訪問時表示:「我欣賞該公司的一點是,他們似乎能提供所有的測試平台,無論你是以軟體模擬,或是進行x-in-loop測試、專有車道測試或公開道路測試,其Foretify解決方案能管理所有的測試格式,提供分析與指標,讓你知道何時達到了完全覆蓋。」

在目前的自駕車測試環境,可用的指標非常有限;通常唯一可行的衡量方法是解除自駕頻率(disengagements),或是自駕車迄今累積的測試里程數。根據美國加州法律,在當地公開道路上進行自駕車測試者,必須公開其行駛里程數,以及人類駕駛被迫取回車輛控制權的頻率,也就是所謂「解除自駕」的危機時刻。

Edge Case Research技術長Phil Koopman曾指出,解除自駕頻率這樣的指標會激勵測試操作員盡量減少人為干預的頻率,因此導致不安全的測試。

Magney也同意這種說法,認為解除自駕頻率是一種「不可盡信」的指標:「在開發階段,你仍在學習並將車輛暴露於各種狀況中,很常見的情況是你將特定技術或方法隔離測試,以觀察它們會在何處遇到困難;換句話說,其實你並沒有執行完整的技術堆疊,因為那反而會更難以確定子系統的性能。」。

他補充指出:「另一個比較偏常識但值得注意的因素,是通常某個系統開發到95%只是一小部分工作,但剩下的5%難度會加倍,而且會是更加危險的部分;」在他看來,那5%的工作包含巨大、多樣化而且只被輕微測試到的行為空間,而Foretellix的工具能解決關鍵問題。

不過與Demler觀點類似,Magny也表示Foretellix的工具比較偏向驗證測試的覆蓋率,而非自駕車的實際開發。

場景描述語言

那麼在場景描述語言方面,M-SDL真的是唯一嗎?對此Binyamini坦承,也有某些標準團體內的公司正在開發場景描述語言,還有其他業者是開發自家內部使用的工具;但產業界傾向於認為,自駕車開發者能從與其他公司共同分享場景而獲益,同時也計劃對其他公司所打造的場景進行審查與重複利用。

Binyamini表示,Foretellix是在一個名為自動化與量測系統標準化協會(Association for Standardization of Automation and Measuring Systems,ASAM)的非營利組織中提出M-SDL;該組織旨在推動車輛開發與測試的工具鏈標準。場景描述語言非常重要,特別是對於正在尋找更接近真實世界、能客觀理解之測試場景的測試工程師來說。

此外Binyamini認為,統一的場景描述語言將有助於建立透明度,讓政府主管機關能看到自駕車測試是如何進行;而主管機關也可以建立一個測試場景的資料庫,確保廠商有相同的理解。因為M-SDL是以高階語言編寫,對主管機關與大眾來說是可閱讀的,有助於建立公眾信任。

Magney也指出,Foretellix並不是唯一想到開發驗證自動駕駛方法的公司。舉例來說,德國的產業聯盟Pegasus,正在為高度自動化駕駛功能打造能被普遍接受的品質標準、工具以及方法,還有測試場景與狀況。

「不過Pegasus是鎖定自動化駕駛功能(L2~L3),而非全自動化駕駛車輛(L4+),使用的是預期性分佈(expected distribution)方法,對於評量預期性故障頻率有用;」Magney表示:「而如Foretellix在其部落格文章中所指出,你需要以非預期性分佈方法,才能確保當非預期故障發生頻率高於一般的情況。」

如果一切按計畫進行,Magney猜測Foretellix會透過持續更新的參數化場景程式庫,為自駕車驗證奠定基礎;然而他也指出:「建立那些場景需要時間,畢竟在ISO 21488,也就是預期功能性安全(safety of the intended functionality,SOTIF)標準的範圍中,你不需要知道所有可能暴露的場景(狀況),你只要及時了解它們。」

編譯:Judith Cheng

(參考原文:EDA, AVs Find Common Language ,by Junko Yoshida)