什麼是 SOTIF？

預期功能安全 (SOTIF) 是為先進駕駛輔助系統 (ADAS) 和自動駕駛系統 (ADS) 應用領域開發的安全方法，可解決系統未故障時存在的感測器和演算法安全問題。 

隨著先進駕駛輔助系統和所有層級的自動駕駛系統興起，ISO 21448 於 2022年制定，旨在為汽車製造商和供應商提供指引，說明在預期功能的功能性不足，或合理可預見的人員誤用所致之危害時，如何確保「不會造成不合理的風險」。這些安全標準共同為所有汽車平台中的自動駕駛系統和 ADAS 提供全方位的方法。ISO 21434 解決了網路安全問題，因為標準組織一致認為，最好提供單一框架來管理整個車輛生命週期中的網路安全風險。

儘管 ISO 21448 中提出的 SOTIF 概念是針對汽車領域開發，但它可以應用於任何自動化系統。企業及組織發現它在航太、重型機械、建築和製造自動化應用領域中非常有用，通常會結合現有的功能安全策略去應用。SOTIF 是一種不斷演進的方法論，全球各地的標準制定組織正在積極完善它，以應對新興技術和應用領域。 

ISO 21448 中的指引旨在補充 ISO 26262 中關於功能安全的指引。功能安全 (FuSa) 處理的是系統故障，SOTIF 則是解決系統沒有故障時的安全問題。

下表說明這兩種汽車安全標準之間的一些差異：

簡而言之，FuSa 可協助工程團隊避免與任何電氣/電子 (E/E) 系統中的軟體和硬體故障相關的安全問題，而 SOTIF 則可解決自動駕駛和駕駛輔助系統接收到不準確的資料、錯誤解讀資料，或被人類駕駛誤用或誤解時，產生的汽車安全問題。 

在針對設備故障制定道路車輛標準後，汽車工程社群發現需要提出安全要求，以解決自動駕駛系統未遭入侵且未故障時，產生的其他潛在危害。ADAS 和自動駕駛系統使用感測器來感知情境，使用機器學習來處理感應器資料，以及使用複雜的演算法來提供資訊、協助或接管駕駛操作。

為了協助工程師開發流程以識別和解決風險，該標準定義三種類型的危險事件：

功能性不足

功能性不足的問題是涵蓋的系統無法準確解讀其營運設計領域 (ODD) 內的真實情況，而導致危險事件。系統的功能性不足包括系統規格中的差距。例如，與超車的摩托車發生碰撞，因為自動化車輛並不知道摩托車會快速接近，而且識別時機過晚。

效能限制

當系統因感測器或演算法的缺陷而以不安全方式運作時，就會發生效能限制。如果一個或多個固有限制是由感測器、演算法或元件造成，可能會導致危險行為。這方面的一個典型範例，是緊急煞車系統無法作用，因為其攝影機感應器碰上大雨或大霧而無法偵測物體。

可預見的誤用

可預見的誤用事件是指使用者以非預期方式互動的情況。例如，使用者在自動駕駛模式下突然轉動方向盤，或在駕駛時分心，未看見或聽見可能發生碰撞的警告訊息。 

一旦團隊發現安全疑慮，他們就會建立情境或案例，假設車輛在道路上可能遇到的情況。ISO 21448 標準定義四個情境領域，代表不同情況的安全和瞭解程度。安全等級可能是安全或不安全，對情況的瞭解則可能是已知或未知。

SOTIF 專注於減少未知和不安全情況的數量，而且會優先探查潛在危險情境，特別是將它們從未知情境轉換為已知情境。下一步是將危險情境轉變為非危險情境。實踐方法是透過改善系統效能，或透過 ODD 限制來避免暴露於此類情境。根據以下所述類別將這些標籤排列成象限圖，有助於安全團隊判斷哪些是危險情境，以及如何設定優先順序。 

隨著適用 SOTIF 的使用案例數量不斷增加，公司正努力將不斷演進的標準，整合至整個產品生命週期的安全機制。雖然在 SOTIF 方面經驗尚淺，但業界已出現一些最佳實作範例，可加速整合、提高 SOTIF 實作的效率，並最終讓搭載駕駛輔助系統、自動駕駛功能的車輛，以及其他利用感測器和 AI 實現自動化和自主的機器更加安全。這些最佳實作範例如下。

• 讓專家參與討論：這是一個新領域，組織內外的專家可以加速實作、提高準確度並增加影響力。
• 利用現場資料：ADAS 和自動駕駛相關感測器，以及使用感測器資料的演算法，會產生大量必要的資訊，可供探查遺漏功能、效能侷限和誤用。
• 以基於模型的系統工程 (MBSE) 方法，整合 SOTIF 流程與 FuSa 和網路安全方法：雖然 FuSa、SOTIF 和網路安全分別解決不同的危害層面和原因，但它們通常能解決相同的危害。此外，類似的資料和安全風險評估工具 (例如故障樹、原因樹和攻擊樹)，也適用於這三個領域。盡可能嘗試重複使用資訊和步驟。當無法共用時，請與其他安全工作同時進行 SOTIF 研究。與基於模型的方法緊密整合，可加速安全分析，確保在分析時將實際系統設定納入考量，而且 FuSa/SOTIF/網路安全分析的結果可傳回開發流程，確保完全可追溯性。
• 結合分析技術與驗證：安全團隊應使用危害分析、危害與可操作性研究 (HAZOP)、原因樹分析以及不充分和觸發條件分析等分析流程，來找出潛在問題。接著，他們應該使用這些資訊來為驗證方法提供資訊，包括道路測試、感應器基準測試、硬體迴路 (HIL)、感應器模擬，以及情境模擬。
• 因應調整 SOTIF 的驗證和確認方法：由於出現新功能，或由於大量潛在情境和觸發條件，SOTIF 通常需要創新的驗證方法。團隊應評估整條驗證和確認 (V&V) 鏈，並視需要修改每個步驟，以納入 SOTIF 所需的資訊。
• 實施虛擬系統訓練和測試：涵蓋 ODD 的測試情境變化為數眾多，而且有數量不斷增加的現場經驗需要補充現有的測試案例。在真實道路上使用真實車輛試駕來進行驗證，是不可能的事。相反地，這類作業大量轉移至模擬環境，包括封閉迴路 (測試整個車輛行為，以及它在現實情境中對其他用路人的反應如何)，以及開迴路 (使用物理準確的感應器模型測試車輛可以感知什麼，或它如何回應特定刺激)。透過模擬進行虛擬測試，也能在設計週期中及早評估和最佳化演算法和感應器設定，並在敏捷週期中對系統進行迭代改良。
• 運用 SOTIF 作為迭代流程：該標準將互動後留下的風險，視為殘餘風險。應再次解決這些殘留的危害，直到剩下的問題不會構成不合理風險為止。
• 讓 SOTIF 成為安全文化不可或缺的一部分：SOTIF 提供不同的視角，說明危害的發生方式和預防方法。參與車輛生命週期的每個人，都應該對此標準有基本的瞭解。 

之所以制定 SOTIF 及其相關標準 ISO 21448，是為了補充現有的產業和公司標準，以及現有的功能安全和網路安全標準。雖然品質與安全團隊努力預測事件，他們依然無法在車輛上路之前找出 SOTIF 涵蓋的所有潛在問題。模擬工具可協助評估 SOTIF 涵蓋的系統，並在整個流程中提供感應器和演算法的資料，以利付諸行動。

公司如果想要讓 SOTIF 流程達到最高的效率、速度和準確度，應考慮以下類型的模擬產品和分析工具。

安全流程規劃和安全案例管理

首先要部署軟體的地方，是使用安全管理工具 (例如 Ansys Digital Safety Manager)，用於引導式安全規劃、安全案例管理、安全計畫執行和審查、模擬、SOTIF 分析，以及 KPI 監控和報告。 

基於模型的系統安全分析工具

制定安全計畫後，適當的基於模型的系統工程 (MBSE) 平台，可讓工程師對系統設計進行安全分析。許多工程師轉而使用 Ansys medini analyze 系統導向安全分析軟體等工具，該軟體支援多種具有端對端可追溯性的 ISO 標準，並完美整合領先的需求管理和 Ansys System Architecture Modeler (SAM) 等系統設計工具。Ansys medini analyze 是系統層級平台的絕佳範例，因為它讓團隊能夠建立和匯入系統架構模型，然後執行不同類型的安全分析，包括：

• 危害分析
• HAZOP
• 故障樹/原因樹/攻擊樹分析
• 可靠度方塊圖
• 故障模式與影響分析 (FMEA)；故障模式、影響與關鍵度分析 (FMECA)；故障模式、影響與診斷分析 (FMEDA)；以及故障模式、影響和故障模式與影響研究 (FMES) 模型。
• 弱點和缺陷分析
• 觸發條件分析

完成後，分析的輸出內容可匯出至所有主要需求管理工具。

情境和感測器模擬平台

實作 SOTIF 的重大挑戰之一，是收集足夠的資料以探查危害。如果團隊想要在危害實際發生之前便加以識別危險的發生，專為自動駕駛車輛空間設計的數位任務模擬平台至關重要。Ansys AVxcelerate Sensors 自動駕駛車輛感測器模擬軟體等工具，可用於建模感測器的功能，能在不依賴實際駕駛記錄資料的情況下，測試和驗證感測器的感知。接著，可以使用 Ansys AVxcelerate Autonomy 軟體等全方位和 MBSE 導向的模擬平台，將 ADAS 和自動駕駛系統測試虛擬化，以大規模情境模擬的形式執行虛擬測試，並為每個基本情境指定許多參數變體。這些資料可以用來量化 SOTIF 的殘餘風險。 

隨著 E/E 在汽車中的使用逐漸增加，ISO 26262 功能安全標準 (即此類系統中的故障和失常行為所造成的危害) 於 2011 年發佈。當 ADAS 系統和所有層級的自動駕駛車輛 (AV) 興起，單憑此標準已不足以解決其所有安全層面問題。因此在 2022 年制定 ISO 21448 標準加以補充，為汽車製造商和供應商提供指引，說明「在預期功能的功能不足，或合理可預見的人員誤用而產生危害時，如何確保『不會因此存在不合理的風險』」(根據 ISO)。後一項標準為汽車產業的原始設備製造商 (OEM) 及其供應商，在設計、確認、驗證和操作汽車 E/E 系統方面提供指引，這些系統利用感應器提供情境感知資訊，然後演算法會使用這些資訊協助駕駛或控制車輛。 

相關資源