隨著科技的演進與人們需求的變化，自駕車的程式碼標準也持續變動。本文將說明自駕車軟體測試中所面臨的挑戰，以及確保程式碼標準合規性的最佳實踐。
與傳統汽車開發相比，自駕技術在開發過程中帶來額外的合規性挑戰。此外，自駕車市場競爭激烈，能夠率先推出經認證的產品者，將在市場中取得重大優勢。因此，開發人員常將靜態分析及其他品質管理活動視為開發的障礙。
儘管在團隊內推動文化認同可能面臨挑戰，但針對安全關鍵型軟體開發所需的品質流程進行教育，是實現更快、更低成本開發流程，並提升文件完整性與合規率的關鍵。那麼，該如何進行自駕軟體的測試呢？
讓我們深入了解無人車、靜態分析、功能安全需求等相關領域。
什麼是自駕技術？
自駕技術是指汽車在無需人工干預的情況下可自動行駛。這項技術結合了人工智慧演算法、感測器、攝影機、微處理器等多種科技。需要注意的是，「自駕（self-driving）」與「全自動（autonomous）」並非完全相同的概念。
自駕車或自動化車輛仍可能在某些時候需要人工介入。而真正的全自動汽車能在無人操作的情況下感知並導航其所處的環境。根據國際自動機工程師學會（SAE）於 2014 年提出的分類，自駕車的自動化程度分為六個等級：
等級 0：系統無法持續控制汽車，只能短暫介入或發出警示。
等級 1：具備先進駕駛輔助系統（ADAS），如倒車影像、自動跟車、車道偏移警示等安全配備。
等級 2：駕駛仍為主控者，但系統能夠協助轉向、加速或煞車。
等級 3：自駕系統可執行如自動停車等任務，但駕駛仍需隨時接手控制。
等級 4：車輛大多數情況下能自動行駛，駕駛可不需時時關注。
等級 5：完全自動駕駛，能應對所有情境。截至本文撰寫時，此等級尚未真正實現。
這個等級制度假設自動化是線性發展的，實際上並非如此。但此分類對於界定汽車自動化程度仍具參考價值。
什麼是自駕車軟體？
自駕車軟體泛指應用於自駕平台的各類軟體。不僅限於人工智慧與機器學習，還包括非自駕車上常見的電子控制單元（ECU）等元件。這些車載電腦資源控制車輛煞車、車門、駕駛輔助系統等功能。而真正驅動自駕功能的是類神經網路。
類神經網路能辨識資料中的模式，供機器學習演算法解析並轉化為動作。例如，當自駕系統偵測到綠燈轉為黃燈，就會啟動減速。
自駕車軟體如何運作？
自駕軟體依靠多種感測器來感知與解析資料，判斷車輛在空間中的位置以及與其他物體（如路緣、他車）的相對位置。其他模組則負責規劃路徑、控制加速、煞車與轉向等行為。
就像人類駕駛車輛一樣，不同的是這些動作全由一套程式、演算法與人工智慧來執行。
什麼是自駕車軟體測試？
所有面向人類使用者的系統一樣，自駕平台需要經過嚴格測試並符合特定標準。ISO 26262 就是汽車產業針對整體產品開發流程所制定的功能安全標準，它協助車廠檢測、管理並降低系統與硬體故障所造成的風險。然而，這套標準不足以涵蓋自駕車所面臨的所有工程挑戰。例如，雖然系統可依設計正常運作，但可能無法因應真實世界中的突發情境，如惡劣氣候或不確定的人類行為，像是小孩突然衝出馬路或醉漢橫越馬路。
為了補足這些真實情境的考量，並分析環境與人類行為，自駕車還需符合 ISO 21448:2021 標準。此標準針對預期功能安全（SOTIF）提供設計、驗證、驗證措施與運作階段的指引。
AUTOSAR（汽車開放系統架構）是由多方業界組織共同合作推動的標準化 ECU 軟體架構。此外，MISRA（汽車產業軟體可靠性協會）則制定一套開發汽車電子元件所需遵循的程式碼撰寫準則。
因此，自駕車軟體的測試不僅是檢查各個元件在失效時是否仍能確保安全，還包括針對真實世界情境的汽車自動反應進行測試。此外，企業也必須證明其自駕軟體符合所有法規要求。
自駕車如何進行測試？
自駕車需要進行真實世界情境的模擬測試，這包括真實的駕駛環境、其他汽車模型以及自動化汽車可能遇到的情況。然而，由於這些系統是電腦化的，也必須針對潛在的網絡攻擊進行風險防範。
理解自駕車軟體的編碼標準
自駕車的編碼標準不斷隨著科技與人類需求的變化而演進。儘管如此，開發人員在為未來的汽車撰寫程式碼時，仍可依賴傳統的安全關鍵合規標準。
軟體產業中的常見編碼標準
不同產業的軟體都有一些共同的編碼標準。然而，編碼標準本身僅是一套規範，列出開發人員應該遵守的程式編寫規則、最佳實踐與指引。
這不僅僅是一些一般性建議，例如限制使用全域變數或標準化命名規則。這些指引或最佳實踐來自擁有數十年軟體開發經驗的專業人士與公司，能有效保證程式碼品質的提升。
從汽車到醫療設備、航空、鐵路等產業，都已採用 C 或 C++ 安全與保安編碼標準。部分標準包括：
- MISRA C 2023 是最新的 C 語言編碼標準，專注於嵌入式系統的程式碼安全性、可靠性、穩定性與可攜性。
- MISRA C++ 2023，即將公布的 C++ 17 編碼標準，針對嵌入式系統的 C++ 程式碼安全性、可靠性與可攜性。
- AUTOSAR C++ 14 是針對嵌入式系統 C++ 14 程式碼的安全性、可靠性與可攜性編碼標準，將會被 MISRA C++ 2023 取代。
- SEI CERT C 是 C 語言的安全編碼標準，旨在識別軟體安全風險，並有效減少應用程式中的漏洞。
- SEI CERT C++ 是 C++ 語言的安全編碼標準，幫助提升軟體安全性並減少應用程式中的漏洞。
自駕車專用的編碼標準
在自駕車領域，團隊應遵循前述的編碼標準，這些標準是高度推薦的，但由於自駕車的特殊性，僅有這些安全與保安編碼標準是不夠的。
其他標準，如 CWE 和 OWASP，則擁有編碼規則與指引，超越了程式碼範疇，還考慮到整體開發流程、組織政策及流程，這些都是確保自駕車安全與保安所必須遵循的。
在考量自駕車及其涉及的先進 AI 系統時，還有其他標準與法規需要遵循。這份清單並不全面，但提供了大致的指引：
- ISO 26262，道路車輛功能安全標準
- ISO 21434，道路車輛網絡安全標準
- ISO 21448，預期功能安全性（SOTIF）標準
- Automotive SPICE，品質管理標準
- UNECE WP.29，車輛網路安全標準
自駕車所需考量的關鍵面向，包括以下幾點：
- 即時性限制：自駕車駕駛過程中的自動化要求系統能夠即時處理資料，因此這些系統必須能夠快速處理大量資料，並瞬間做出決策。
- 網路安全：車輛被駭客攻擊是個嚴重問題，編碼標準應確保有因應這種情境的措施。
- 人機互動: 人類行為難以預測，開發者需預留對突發情況的應對方式。
自駕車軟體測試中的挑戰
開發自駕車軟體固有的安全關鍵性質，導致了對徹底且持續測試的需求。但像所有軟體開發一樣，創建 AI 驅動的系統也面臨許多挑戰。
- 遵守多重編碼標準：這需要規劃、持續測試，並要求開發人員在撰寫程式碼時要格外注意。
- 網路安全風險： 所有電腦化系統都可能面臨安全風險。例如，駭客接管自駕車的情況，應該在開發與測試過程中提前預料並做好防範。
- 舊有程式碼： 無論是自己過時的程式碼，還是繼承來的程式碼，舊程式碼可能成為開發過程中的障礙。可以用兩個口訣來處理：一是「邊寫邊清理」，二是「零新增違規」。
- 車輛數據收集：需要即時收集、解析並檢視大量的新資料，才能實現真正的自駕。為此，強健的資料收集系統至關重要。
- 技術債務：某些開發人員希望提高效率，選擇在測試前不強制遵守編碼標準。這可能會導致原型中包含不符合安全標準的程式碼，從而引發延遲。最好的做法是「邊寫邊清理」。
- 測試的限制：一次只測試一個原型會延遲任何更新，並且錯誤的代價可能是巨大的。
- 適合自動化的基礎設施： 目前的公共道路和高速公路對自駕車構成了重大障礙，因為這些道路是為人類駕駛者設計的。開發這些系統的軟體可能因此受阻。
- 技術演進：AI 和機器學習技術迅速變化，自駕車所涉及的輔助技術，如感測器、雷達等，也在不斷更新。
確保編碼標準合規的最佳實踐
達成合規並非易事，即便是最有經驗的專業人士也可能在某些方面出錯。然而，有一些通用的最佳實踐，適用於所有軟體工程師，這些做法對於自駕車軟體開發以外的領域也有益處。
從一開始就設立編碼標準
無論是專案範圍、時間表或預算，從一開始就設立期望與標準都是至關重要的。這不僅能確保團隊成員更容易理解程式碼，還能確保在處理錯誤時能更迅速，避免像玩傳話遊戲或猜謎一樣的情況發生。
定期程式碼檢討與稽核
與持續測試類似，定期進行程式碼檢討可以幫助更好地執行標準並及早處理問題。這樣可以發現程式碼深層巢狀結構、難以閱讀的程式碼、命名規範是否正確等問題。
持續訓練與技能發展
即使是領域中的專家，擁有學習心態仍有助於提升能力。因此，投資開發人員的教育與訓練，超越他們最初被聘用時的職責，是值得的。而且，科技不斷進步，這意味著您的團隊必須持續學習與跟上步伐。
善用自動化與工具
靜態分析測試不是每位開發人員的最愛，但自動化使得這類測試變得更容易實施。在敏捷或「向左移」的開發流程中，善用所有可用工具，包括 AI 和機器學習，已成為理所當然的選擇。
文件與報告
再次強調，避免問題的最簡單方法是從一開始就防範。文件與報告可以讓團隊根據需要進行交叉參照，而不必花額外時間追蹤最初撰寫程式碼的人。更糟糕的是，團隊可能僅憑假設前進，進而使用無法使用的程式碼。
測試的好處
導入靜態分析工具，搭配即將公布的MISRA C++ 2023和即將成為舊版的AUTOSAR C++ 14編碼標準，將合規性作為可持續過程看似令人畏懼。但即使在像自駕車這樣創新領域，測試仍然是最佳實踐的重要組成部分。
使用如Parasoft的C/C++test等工具進行測試，能將以下好處融入您的工作流程：
認證與合規性： 所有汽車組織都將ISO 26262認為是主要的功能安全標準，這能簡化批准和認證流程。自駕車軟體在量產前必須獲得批准和認證，因此提前且頻繁地進行測試有助於更快地達成認證。
以較低成本達成高品質：從一開始就構建高品質且合規的程式碼，並盡早進行測試，有助於更快解決問題。開發人員從一開始就會採用最佳實踐，從而避免常見的陷阱。在編寫程式碼的同時進行測試對於快速創建複雜軟體至關重要。靜態分析是其中一種適合此流程的方法。
問責制與文檔記錄： 在路上有數百萬輛車，事故難免會發生，其中一些將追溯到軟體錯誤。組織必須能夠證明他們已經採取了一切實際可行的措施來防止安全隱患。擁有一個記錄下來的編碼標準合規流程將證明是有益的。
封閉迴路系統中的測試：在虛擬環境中創建測試案例有助於降低測試成本和時間。模擬各種情境進行分析，能夠在測試過程中進行細微的調整或重大修改，從而獲得更多可操作的資料。
自駕車軟體測試的未來趨勢與考量
市場上有許多公司試圖成為第一家推出真正自駕車的企業。這項技術需要全面的測試，以保障生命安全、正常運作並適應日常生活。
儘管這不是來自美國國道交通安全管理局（NHTSA）的官方文件，電氣與電子工程師學會（IEEE）在2022年發布了一份針對ADS標準的初步指導方針。IEEE P2846草案標準針對安全相關自動駕駛車輛行為模型的假設，旨在解決自駕與駕駛過程中的獨特問題。然而，對於這個使用案例，擁有標準指導方針並非唯一的未來考量。
如前所述，自駕車軟體測試也依賴於現實世界來迎接真正的自駕車。隨著自動駕駛的廣泛普及，導航的傳統技術和方式可能需要改變。這引發了一個問題：如果城市是圍繞人類使用而非停放車輛來設計的，會是什麼樣子？
總結
將靜態分析或其他類型的持續測試整合到您的工作流程中，可以產生實際成果。但使用像Parasoft多種解決方案之一，將使達成自駕車軟體的安全合規變得更加可行。只需記住以下幾點：
- 明確了解測試的目的。
- 解決延遲發布的成本問題。
- 盡可能使採用過程相關且無縫。
- 有目的地實施靜態分析工具。
- 選擇適合的規則與檢查器，以便與開發人員流程整合的工作流程。
以效率、徹底和以開發人員為導向的目標，您將比預期更快達成安全合規。
本文由Parasoft提供