智慧座艙 AI 語音助理落地:功能安全 ISO 26262 與車用資安 ISO/SAE 21434 要點

去年我們協助一家 Tier 1 座艙供應商收尾一個語音助理專案。Demo 那天很順:駕駛說「我有點冷」,空調自己升兩度;說「找最近的超充」,導航直接帶路。客戶主管當場鼓掌。三個月後量產前的安全評審會上,這套系統被功能安全團隊擋了下來。

不是因為它不好用。是因為沒有人回答得出一個問題:當語音助理誤聽指令、去動了跟行車相關的功能時,誰來把關?

智慧座艙 AI 的落地,卡的不是模型,是兩張合規門票

智慧座艙 AI 語音助理最容易被低估的一點,是它不只是個聊天介面。它一旦能控制車輛功能、能連雲端、能被 OTA 更新,就同時踏進了兩個車規世界:功能安全(ISO 26262)與車用資安(ISO/SAE 21434)。前者管「系統壞掉會不會害到人」,後者管「系統被攻擊會不會害到人」。語音助理很特別,兩邊都躲不掉。

我們踩過的第一個雷,就是把所有語音指令當成同一種東西處理。實際上,你得先做指令分級。

功能安全:先把語音指令按 ASIL 分類

ISO 26262 的核心是危害分析與風險評估(HARA),推導出每個功能的 ASIL 等級(QM 到 ASIL D)。語音助理的關鍵動作,是把「一句話能觸發什麼」攤開來對照:

我們給客戶的硬規則是:凡是 ASIL B 以上的功能,語音絕不能是唯一的觸發路徑。誤喚醒率、語音辨識錯誤率這些平常拿來吹的指標,在這裡要當成安全參數來管——一個 5% 的誤觸發,如果後面接的是駕駛模式切換,那就是安全事件,不是體驗問題。

另一個常被忽略的檢查點:語音助理本身的 HMI 是不是製造分心。畫面跳動、語音打斷、回覆過長,都可能讓駕駛視線離開路面。這部分沒有單一數字達標就算過,得做人因實測。

資安:語音資料一上雲,就進了 ISO/SAE 21434 的射程

只要你的語音要走雲端大模型、要 OTA 更新模型,攻擊面就開了。21434 要求做 TARA(威脅分析與風險評估),對語音助理我們會盯這幾條:

麥克風與喚醒詞是最前緣的入口,要防的是惡意音訊注入與跨車廣播攻擊——有研究能用人耳聽不到的超音波下指令。語音資料上傳鏈路必須端到端加密,且要能回答一個隱私問題:駕駛的語音樣本存哪、留多久、誰能調。模型的 OTA 更新要有簽章驗證與回滾機制,否則一次被污染的模型推送,等於同時黑掉整個車隊。最後,雲端斷線時的降級行為要設計好:斷網不該讓安全相關功能失效或誤動作,而是安全地退回本地基本模式。

這兩張門票的共通點是:它們都要求你在寫第一行程式之前,就先把「這句話最壞會怎樣」想清楚,而不是等 Demo 驚豔完再補文件。

我們的做法

Tenten 在做車用座艙的 AI 導入時,不會先問模型多聰明,而是先跟客戶的功能安全與資安團隊一起,把語音指令攤成上面那張表——哪些走 QM、哪些踩 ASIL、哪些觸發 TARA 條目,對應到具體的聯鎖、確認與降級設計。工程師直接進到你的驗證流程裡,把語音助理從一個漂亮的 Demo,推到真的敢掛在量產車上、且審查會議過得了關的狀態。Demo 讓人點頭很容易,能上線、有人天天在開車時安心用它,才算數。