智慧座艙 AI 語音助理落地:功能安全 ISO 26262 與車用資安 ISO/SAE 21434 要點
語音助理在座艙 Demo 上驚豔很容易,難的是通過量產前的安全評審。一旦它能控制車輛功能、連雲端、被 OTA 更新,就同時踏進 ISO 26262 功能安全與 ISO/SAE 21434 車用資安兩個世界。這篇用一個被擋下的真實案子,拆解語音指令該如何分級、哪些檢查點決定它上得了車。
작성자
Tenten AI 交付團隊
產業交付
게시일
2025년 10월 23일
읽는 시간
5 分鐘
去年我們協助一家 Tier 1 座艙供應商收尾一個語音助理專案。Demo 那天很順:駕駛說「我有點冷」,空調自己升兩度;說「找最近的超充」,導航直接帶路。客戶主管當場鼓掌。三個月後量產前的安全評審會上,這套系統被功能安全團隊擋了下來。
不是因為它不好用。是因為沒有人回答得出一個問題:當語音助理誤聽指令、去動了跟行車相關的功能時,誰來把關?
智慧座艙 AI 的落地,卡的不是模型,是兩張合規門票
智慧座艙 AI 語音助理最容易被低估的一點,是它不只是個聊天介面。它一旦能控制車輛功能、能連雲端、能被 OTA 更新,就同時踏進了兩個車規世界:功能安全(ISO 26262)與車用資安(ISO/SAE 21434)。前者管「系統壞掉會不會害到人」,後者管「系統被攻擊會不會害到人」。語音助理很特別,兩邊都躲不掉。
我們踩過的第一個雷,就是把所有語音指令當成同一種東西處理。實際上,你得先做指令分級。
功能安全:先把語音指令按 ASIL 分類
ISO 26262 的核心是危害分析與風險評估(HARA),推導出每個功能的 ASIL 等級(QM 到 ASIL D)。語音助理的關鍵動作,是把「一句話能觸發什麼」攤開來對照:
| 語音指令類型 | 觸及的車輛功能 | 典型 ASIL | 落地檢查點 |
|---|---|---|---|
| 「調高溫度」「放首歌」 | 舒適/資訊娛樂 | QM | 誤觸發僅造成困擾,可用二次確認緩解 |
| 「開啟車道置中」「切換駕駛模式」 | ADAS/動力 | B–D | 語音不得為唯一觸發路徑,須實體確認 |
| 「打開後車門」(行進中) | 車身安全 | B | 需車速聯鎖,行駛中拒絕執行 |
| 免持通話、閱讀訊息 | 駕駛分心(HMI) | 依情境 | 對照 NHTSA/歐盟分心準則做人因驗證 |
我們給客戶的硬規則是:凡是 ASIL B 以上的功能,語音絕不能是唯一的觸發路徑。誤喚醒率、語音辨識錯誤率這些平常拿來吹的指標,在這裡要當成安全參數來管——一個 5% 的誤觸發,如果後面接的是駕駛模式切換,那就是安全事件,不是體驗問題。
另一個常被忽略的檢查點:語音助理本身的 HMI 是不是製造分心。畫面跳動、語音打斷、回覆過長,都可能讓駕駛視線離開路面。這部分沒有單一數字達標就算過,得做人因實測。
資安:語音資料一上雲,就進了 ISO/SAE 21434 的射程
只要你的語音要走雲端大模型、要 OTA 更新模型,攻擊面就開了。21434 要求做 TARA(威脅分析與風險評估),對語音助理我們會盯這幾條:
麥克風與喚醒詞是最前緣的入口,要防的是惡意音訊注入與跨車廣播攻擊——有研究能用人耳聽不到的超音波下指令。語音資料上傳鏈路必須端到端加密,且要能回答一個隱私問題:駕駛的語音樣本存哪、留多久、誰能調。模型的 OTA 更新要有簽章驗證與回滾機制,否則一次被污染的模型推送,等於同時黑掉整個車隊。最後,雲端斷線時的降級行為要設計好:斷網不該讓安全相關功能失效或誤動作,而是安全地退回本地基本模式。
這兩張門票的共通點是:它們都要求你在寫第一行程式之前,就先把「這句話最壞會怎樣」想清楚,而不是等 Demo 驚豔完再補文件。
我們的做法
Tenten 在做車用座艙的 AI 導入時,不會先問模型多聰明,而是先跟客戶的功能安全與資安團隊一起,把語音指令攤成上面那張表——哪些走 QM、哪些踩 ASIL、哪些觸發 TARA 條目,對應到具體的聯鎖、確認與降級設計。工程師直接進到你的驗證流程裡,把語音助理從一個漂亮的 Demo,推到真的敢掛在量產車上、且審查會議過得了關的狀態。Demo 讓人點頭很容易,能上線、有人天天在開車時安心用它,才算數。
