SOTIF（ISO 21448）是什麼？功能安全管故障，誰管沒故障也出事

自動緊急煞車在高架橋下無故觸發——查了三週：雷達沒壞、軟體沒有 bug、每個元件都照規格運作。問題出在設計本身：橋墩的雷達回波特徵跟靜止車輛太像，而這個場景不在當初的設計考量裡。這就是 ISO 26262 管不到的領域——沒有故障（fault），卻有危害（hazard）。**ISO 21448 SOTIF（Safety Of The Intended Functionality，預期功能安全）**管的就是這一塊。

故障 vs 性能不足：兩份標準的分工

• ISO 26262 的世界觀：系統的正確行為可以完整定義，危害來自偏離正確行為——硬體隨機失效、軟體系統性錯誤。對策是失效率量化、診斷覆蓋、ASIL 分級的開發嚴謹度。
• SOTIF（ISO 21448，2022 年發布） 的世界觀：系統完全照設計運作，危害來自設計的性能極限——感測器的物理限制、演算法的辨識盲區、對場景的錯誤假設。對策不是消除故障，是把「設計應付不了的場景」找出來。

ADAS 是 SOTIF 的主場：感知與決策的性能極限直接決定安全，而這些極限往往要到特定的**觸發條件（triggering condition）**出現才暴露——低角度逆光、隧道出口的亮度突變、被雨水覆蓋的車牌。

四象限：SOTIF 的核心思考模型

SOTIF 把所有場景切成四塊：已知安全（驗證過、沒問題）、已知不安全（找到了性能極限，改設計或加限制）、未知不安全（還沒發現的危險場景——最危險的一塊）、未知安全。整個 SOTIF 流程就是一個轉移工程：把未知變已知、把已知不安全變安全，直到殘餘的未知不安全風險小到可以接受、並且論證得出來。

這個「論證得出來」是關鍵——SOTIF 是迭代流程：設計規格 → 開發 → 驗證與確認，發現新的觸發條件就回頭改，直到殘餘風險的論證能說服稽核方。

場景測試：把未知挖出來的引擎

未知不安全的場景不會自己現身，要靠系統性的方法挖：

• 場景庫與觸發條件分析：從 ODD（設計運行域）出發窮舉環境因素的組合——天候、光照、道路幾何、交通參與者行為——找出可能踩到性能極限的組合。
• 模擬批次執行：組合爆炸靠模擬消化。DYNA4 的場景引擎原生支援 ASAM OpenSCENARIO、OpenDRIVE 與 OSI 標準，把場景參數化後批次生成變體，一夜掃過實車一年也遇不完的組合；搭配 CANoe.ADAS 把感知輸出與真值（ground truth）同步比對，性能極限出現的瞬間就被記錄。
• 實車確認：模擬篩出的關鍵場景在封閉場地與路測確認——模擬找面、實車驗點，順序反過來成本會失控。

發現的每個觸發條件都回饋到四象限：改設計（提升性能）、加限制（縮小 ODD）、或論證接受（殘餘風險）。這條迴圈與 ISO/PAS 8800 的 AI 安全生命週期直接銜接——感知用了機器學習的系統，兩份標準的場景庫與驗證基礎建設是共用的。

常見問題釐清

SOTIF 是什麼？

SOTIF（ISO 21448，預期功能安全）處理「沒有故障、系統照設計運作，仍因設計的性能極限而產生危害」的問題——感測器物理限制、演算法盲區、場景假設錯誤。方法是系統性地找出觸發條件，把未知不安全的場景轉成已知並處理，直到殘餘風險可接受且論證得出來。

SOTIF 跟 ISO 26262 一定要一起做嗎？

做 ADAS／自動駕駛功能的話，是。26262 管故障（元件壞掉怎麼辦），SOTIF 管性能（元件都沒壞但應付不了場景怎麼辦）——兩者的危害來源不同、對策不同，缺一邊的安全論證就有洞。實務上兩邊應共用系統定義與危害分析的基礎，避免各做各的。

SOTIF 的場景測試要做到多少才夠？

SOTIF 不給固定數字，要求的是論證：殘餘的未知不安全風險已透過系統性的方法（觸發條件分析、參數化場景掃描、實車確認）壓縮到可接受水準。實務關鍵是場景庫的系統性——用 ODD 驅動的參數組合覆蓋，而不是憑經驗湊案例；模擬批次執行讓覆蓋規模成為可能。