工研院資通所 曾志宏、黃浚鋒
自駕車為一個軟硬體高度整合之系統[1]，除了煞車、油門、轉向等控制系統以外，另有由攝影機、光達、雷達等多組感知元件偵測周邊環境，透過決策模組決定載具的行進狀態；像自駕車這樣的無人載具在運行時，其行為是由周邊環境、軟體、硬體之間的複雜互動所決定，大眾會預期自駕車在各種不同的場景條件下皆符合安全駕駛的條件，故在把自駕車推到市面時，需要執行過一系列嚴謹的測試。然而，自駕車的開發是個漸進式的，對於任何一個在軟硬體上的改變，都需要有一套方式確認在每次的改動後，系統會變得更好或是仍保持原水準表現，本文即探討實務上，如何使用自動化技術做自駕車的整合測試，讓開發的過程及自駕車的品質變得更可控，即：（一）自動找出潛在的程式缺陷、（二）自動找出模組之間的溝通介面問題、（三）自動找出車輛在行進時出現的異常行為。
精彩內容
1. ISO 26262 V模型
2. 自動化整合測試技術
3. 靜態測試與動態測試
4. 實車線上檢查測試
ISO 26262 V模型
由於自駕車在公眾場合運行，若其出現不當的駕駛行為會造成人身及財產上的損害， 故各國政府皆有法令約束自駕車的規格及行為， 國際上亦制定ISO 26262 [2] 的車規標準，其中採用V模型設計架構（圖1），以期功能安全需求等級得到一致性的分析結果。
圖1：V模型（圖片來源：[3]）
在V模型裡，左側代表設計到實作，右側則是驗証功能，雖然V模型被ISO 26262採用並被業界接受，但並沒有表列具體的測項，另外，V模型假設原始碼可以正常編譯及執行，也假設左側上方欄裡的需求為已知、完整、沒有模糊空間的，但自駕車的開發流程和現實運作情況並非這麼理想[3]，故如何產生出足夠的測項亦為一個研究領域[4]。另外，當測試項目為自動產生時，就需要依賴電腦的自動化執行才能在合理的時間內將測項執行完，以落實V模型右側的項目。
另外一個考慮點是在何時執行測試項目，我們傾向在系統有改動時就執行，每次改動就會有一個對應的測試報告，若有測項從通過變成不通過，我們不只找到系統的缺陷，同時也明確知道缺陷是那次改動造成的，在追查成因時會更有效率。我們甚至可以更進一步，在提交改變前就執行測試，若有測項不通過則拒絕其修改，避免有缺陷的程式進入正式的系統並影響到團隊的正常運作。
測試架構
圖2為各軟體元件及實車整合的架構圖，我們對照ISO 26262的規範，搭配現有的軟體工具實踐V模型，對於每個模組規格、程式規格、子系統規格、系統規格、使用者需求，我們判斷其對應的測試項目放在那個階段執行才比較妥適，我們儘量把測試項目設計成可以在實驗室裡快速執行，若此要求不可行，才將測試項目放到實車上執行，達到在契合V模型的情況下有效率得執行自動化測試。
具體而言，我們使用 gitlab 儲存程式碼，Jira做議題追蹤，後台(（backend)）做實車事件記錄，buildbot master做測試事件的排程，buildbot worker負責執行測試，當有提出合併請求等事件觸發或是測試結果出來時，會透過電子郵件通知相關人。為了使整個測試環境的建置成本最小化，我們使用虛擬化技術，讓單一主機負責多個獨立的服務區塊。
圖2 測試架構圖
靜態測試與動態測試
由於實車測試比較耗時，因此我們會在實驗室裡建構一個和實車儘量相同的環境，測試除了控制以外的項目；其中buildbot master會主導整個測試的時程，在事件有觸發時執行指定的測試內容。
表1為執行測試的時間點及內容，git主線為實車運行的程式，當分支裡的改動要合併至主線時，先進行compile、linter、以及publish test檢查，檢查通過後才允許能被合併回主線。在合併之後，會根據每種測項的特性及執行時間在不同時期檢查，逐步擴大檢查的範圍。
表1 不同時期的測試項目
| 觸發時機 | 測試項目 |
| pre-merge | compile, linter, style check, publish test |
| post-merge | unit test, full publish test |
| nightly | all items in pre-merge and post-merge, cppcheck, scan-build, accuracy calculation, publish test with sanitizers |
| weekly | coverity |
實驗室的測項主要分為靜態測試及動態測試2類，靜態測試沒有涉及執行實車上的程式，動態測試則有。靜態測試會使各種主流的測試工具，包括使用clang確認C++程式碼符合C++標準，clang-tidy和cppcheck檢查是否有語法風格和效能改進的地方，scan-build檢查是否有memory leak或邏輯錯誤，coverity檢查程式碼是否達到車用程式的標準。
在動態測試部分，有單元測試負責測試函式層級的正確性，由於ROS（Robot Operating System）系統已整合google test的測試框架進來，同時又因為單元測試執行速度快且會干擾單元測試運算結果的因素少，因此建議撰寫單元測試。另一個動態測試為發布測試（publish test），其作用在檢查模組的功能是否正常以及與其他模組的通訊是否順暢，在一個發布測試項目裡，我們會啟動欲測試模組的程式，同時在背景播放資料（用來復現自駕車在路上行進的狀態），背景播放的資料會包含該模組所需要的所有輸入，在計算出結果後，模組會把計算結果發布在指定的頻道上，發布測試就靠著監聽指定頻道上是否有預期的資料出現，判斷測試項目是否通過。
在常規的發布測試之外，我們還有利用當代編譯器提供的Sanitizer檢查程式是否有缺陷，編譯時沒有加入Sanitizer的話，隱性的程式缺陷如race condition或錯誤的記憶體存取並不會立即外顯出來，而是在一段時間之後，程式才出現異常狀況，這使得偵錯工作變得困難，相對於此，在編譯時使用Sanitizer後，程式在執行到缺陷處時會立即崩潰或是顯示出錯誤訊息，利用這一特性，發布測試可以有效找出程式的缺陷處。
實車線上測試
在自駕車行駛過程中，還有一組程式檢查是否有異常情況發生，圖3條列檢查的項目，依嚴重程度來說，程度為FATAL者有自駕車的程式不正常終止（crash）、定位失敗、剎車失效，程度為ERROR者有自動緊急剎車、司機介入剎車、X-by-wire未打開等等，其他諸如物件偵測的效能及信心度也在偵測範圍內，當有條列之異常情況發生時，檢查程式會將相關的資訊透過網路送回後台做記錄，以便事後追溯。
圖3 安裝於自駕巴士上之線上檢查器與其檢查項目
結論
本文詳述自駕車之自動化整合測試技術，為依據ISO 26262規範，搭配現有的軟體工具實踐V模型，從基本的靜態分析、到程式動態分析、再到實車的線上分析，將自動化測試充分應用到無人載具的開發過程。透過系統化的測試，可自動找出潛在的程式缺陷、模組之間的溝通介面問題，以及自動找出自駕車在行進時出現的異常行為，將系統的良窳情況即時反應給開發人員知曉，在問題出現時立即做出修正，有效加速自駕技術之研發。
參考文獻
[1] E. Yurtsever, J. Lambert, A. Carballo and K. Takeda, “A Survey of Autonomous Driving: Common Practices and Emerging Technologies”, IEEE Access, vol. 8, pp. 58443-58469, 2020.
[2] Road vehicles — Functional Safety — Part 2: Management of functional safety, ISO 26262-2:2011, Nov. 15, 2011.
[3] P. Koopman and M. Wagner, “Challenges in Autonomous Vehicle Testing and Validation”, SAE International Journal of Transportation Safety, vol. 4, no. 1, pp. 15-24, 2016.
[4] W. Huang, K. Wang, Y. Lv and F. Zhu, “Autonomous vehicles testing methods review”, IEEE 19th International Conference on Intelligent Transportation Systems（ITSC）, pp. 163-168, 2016
