點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

一個目標檢測模型在測試集上達到99%準確率，能否證明它適合安全相關車輛功能？不能。ISO/PAS 8800試圖填補的正是這段距離：怎樣把數據、模型、場景、架構、運行監控和變更管理組織成一套可信的車載AI安全論證。

ISO/PAS 8800:2024在2024年12月發布，適用于量產道路車輛中使用AI技術的安全相關E/E系統，重點關注機器學習。它處理AI輸出不足、系統性錯誤和隨機硬件錯誤可能造成的車輛級不期望安全行為。

這份規范并沒有提供一個神奇的準確率門檻，也不限定必須使用哪種神經網絡。它要求項目識別AI特有風險，定義安全相關屬性，并用證據說明不存在不可接受風險。

ISO 26262擅長處理E/E系統故障：硬件隨機失效、軟件系統性缺陷、開發流程和安全機制。傳統軟件可以從明確需求推導實現，再通過測試和分析驗證一致性。

機器學習的行為部分來自訓練數據。開發者沒有逐條編寫決策邏輯，模型可能在訓練分布之外產生難以預料的輸出。需求、實現和驗證之間不再是傳統的一一映射。

ISO 21448 SOTIF處理沒有故障時的功能不足和觸發條件，尤其適合復雜傳感器與感知功能。ISO/PAS 8800進一步聚焦AI元素本身的安全屬性、數據與模型生命周期。

圖1｜ISO 26262、SOTIF與ISO/PAS 8800覆蓋的風險側重點

ISO 26262：重點回答系統發生硬件或軟件故障時，如何避免不合理風險。

ISO 21448：重點回答功能按設計運行但能力不足或場景未知時，如何控制風險。

ISO/PAS 8800：重點回答AI元素的數據、模型、輸出不足和不確定性如何進入安全保證。

三者不是替代關系。一個AI感知功能可能同時需要功能安全、安全預期功能和AI安全工作產品，并最終匯入同一個車輛級安全案例。

模型輸出錯誤只是表面。根因可能來自問題定義、傳感器覆蓋、采集策略、標注、數據清洗、訓練過程、模型轉換、硬件量化、運行環境漂移或后續更新。

數據不足：關鍵場景缺失、樣本分布偏差、標簽錯誤或訓練與目標市場不一致。

模型不足：對遮擋、天氣、長尾對象或域外輸入缺乏穩定行為。

實現不足：模型轉換、量化、加速器算子或編譯優化改變了輸出。

集成不足：上下游接口、時間同步、預處理或后處理與訓練假設不一致。

運行漂移：道路、傳感器、法規或用戶行為變化，使量產數據偏離開發分布。

圖2｜AI安全證據必須貫穿數據、模型、集成與運行階段

因此，AI安全不能只由算法團隊負責。系統、傳感器、數據平臺、軟件、SoC、測試、功能安全和運營團隊都持有證據鏈的一部分。

平均指標會掩蓋危險場景。一個模型在白天直路樣本上非常優秀，卻可能在夜間施工、逆光、污損鏡頭或罕見道路參與者上系統性失效。

安全需要按場景和后果分解性能。漏檢遠處廣告牌與漏檢近距離行人不是同一風險；相同的誤檢率，在緊急制動與舒適功能里也有不同意義。

需要保持克制：“測試集沒有發現問題”只能證明已測試樣本。對開放道路場景，項目還必須論證測試集為何足以代表目標ODD，以及未覆蓋空間怎樣通過架構和運行約束控制。

傳統安全項目嚴格管理需求版本，卻常把數據當作算法團隊的工作文件。對于機器學習，數據實際上定義了模型行為的一部分，必須具備接近代碼和需求的配置管理。

每個數據集需要記錄來源、采集條件、同意與使用邊界、傳感器版本、標注規則、質量檢查、去重方法、拆分策略和已知缺口。

標簽也不是絕對真值。不同標注者對遮擋對象、可行駛區域或意圖可能存在分歧。項目需要定義不確定標簽、仲裁規則和一致性指標，而不是強行把模糊世界壓成一個確定答案。

圖3｜從原始數據到安全證據的數據治理閉環

合成數據可以補充危險和稀有場景，但需要證明模擬與真實世界的相關性。生成式AI用于生成場景、標簽、代碼或測試時，還要驗證生成過程是否被正確grounding，不能把生成內容直接當作事實。

傳統軟件也會失敗，但機器學習輸出通常帶有統計性和不確定性。安全架構不能把模型當成永遠正確的黑盒，而要限制它能造成的后果。

輸入監控：檢測傳感器遮擋、失真、時間戳異常和域外輸入。

輸出合理性檢查：用物理約束、地圖、運動學或獨立算法過濾不可能結果。

冗余與多樣性：使用不同傳感器、不同算法或確定性規則避免共同原因失效。

置信度門控：模型不確定時限制功能、請求駕駛員接管或進入更保守策略。

最小風險狀態：定義AI能力不足或計算平臺異常時車輛如何降級。

監控器本身也要進入安全分析。如果它使用相同數據、相似模型和相同計算鏈，所謂冗余可能只是重復同一個弱點。

圖4｜讓AI受監控、受約束并具備確定性降級路徑

量產后環境會變化。新型交通設施、道路施工方式、傳感器老化、用戶行為和軟件版本都會改變輸入分布。開發階段的安全結論必須通過車隊監控持續維護。

項目需要定義哪些運行數據可采集、怎樣保護隱私、如何檢測分布漂移、什么閾值觸發調查，以及發現系統性風險后怎樣限制功能或回滾模型。

這里容易出現閉環陷阱：只采集模型認為“有趣”的數據，可能錯過模型根本沒有意識到的失敗。運行監控要結合獨立事件、駕駛員接管、其他傳感器和事故近失數據。

軟件補丁通常修復可定位的代碼缺陷。重新訓練模型時，即使只增加一類數據，也可能改變整個輸入空間中的決策邊界。局部改進不保證其他場景不退化。

回歸策略：既驗證修復場景，也驗證所有關鍵場景與先前安全屬性。

版本可追溯：車輛上運行的模型必須能追到數據集、訓練代碼、工具、參數和批準記錄。

部署控制：灰度、監控、回滾和車型配置必須與OTA系統聯動。

持續學習不意味著車輛可以未經控制自行改變安全相關模型。任何在線或車隊閉環學習都需要清楚的批準邊界與再驗證策略。

供應商需要說明預期用途、輸入假設、訓練數據邊界、已知限制、目標硬件、性能置信區間、監控建議和變更歷史。OEM則要驗證這些假設在具體車型、傳感器布置和ODD中成立。

第一，限定用途和ODD：先說清AI負責什么、不負責什么，以及超出邊界怎樣處理。

第二，建立AI風險清單：從數據、模型、工具、硬件、集成和運行六個維度識別失效。

第三，定義安全相關屬性：把性能、魯棒性、可預測性、不確定性和可監控性轉換成可驗證要求。

第四，設計約束架構：在模型之外建立輸入監控、合理性檢查、冗余和降級。

ISO/PAS 8800最大的價值，是把討論從“模型準不準”推進到“整個AI生命周期是否可信”。它不承諾消除所有未知場景，而是要求項目對未知、輸出不足和變更保持可論證的控制。

真正的安全結論不能只來自一次測試，而要來自一條連續證據鏈：問題定義正確，數據足夠且可追溯，模型在關鍵場景滿足要求，架構能夠限制錯誤，運行階段能夠發現漂移，更新后仍能維持安全屬性。

對汽車軟件團隊而言，AI工程正在從算法競賽轉向安全工程。誰能把數據、模型、系統架構和車隊運營連接起來，誰才真正具備量產AI的能力。

來源：人與車科技