如何借助一定的工具鏈開展SOTIF標準的安全分析過程

1、預期功能安全來源與現狀

傳統電子電氣領域問題，可通過功能安全解決。但隨著自動駕駛技術的發展，加入了包括算法、圖像識別等內容，僅保證自身無故障已經不足以滿足自動駕駛對于安全的需求。

由于自動駕駛系統本身的高度復雜性，導致了我們設計的功能本身就有局限性或缺陷，從而進一步導致安全事故的發生，預期功能安全試圖解決的就是這些問題。預期功能安全就是在這樣的背景下提出了。

本文將重點講解如何通過SOTIF標準更好的解決智能駕駛開發中功能不足的問題和設計局限性導致的風險，如何驗證和確認當前的危害是合理可接受的，如何正確采用標準要求的技術方法（FMEA/CTA/STPA）。同時本文將依托NOA功能實例，重點講解如何借助一定的工具鏈開展SOTIF標準的安全分析過程。

在以NOA為例進行預期功能安全分析的過程中，需要考慮其主要原因是在設計和開發期間對系統功能的定義不能完全涵蓋目標市場的使用需求。其中，對目標場景的考慮的不全面，導致系統不能準確識別環境要素；功能仲裁邏輯不合理，將導致系統決策錯誤；執行器響應不充分，則會導致運動控制偏離預期。

2、預期功能安全分析理論基礎

自動駕駛會受到很多因素的影響，比如路況、周圍事物和環境天氣。如何克服環境干擾，可靠地進行環境識別、駕駛決策和運動控制是確保安全駕駛的關鍵。

對于NOA來講，預期功能安全要求在危害分析和風險評估的過程中對影響安全的功能需求進行FEMA，FTA，HAZOP，SPTA，CTA等工具進行分析和驗證。

其中FEMA，FTA，HAZOP等是ISO26262功能安全分析常用的工具。

此外，Hazard的分析涉及傳統意義上的危害分析，包括功能、HAZOP、危害行為描述、失效影響（主要是指整車層級危害）這幾個方面。

對于自動駕駛領域，自動駕駛汽車功能的實現依賴于與外部環境的交互，傳統基于事件鏈模型的危害識別方法無法適用于這類開放系統。

而在預期功能安全的分析方法則更倡導基于控制理論的系統理論過程分析（SPTA）來進行自動駕駛汽車危害識別。

如下圖表示了NOA中典型的STPA 搭建駕駛員、車輛、環境交互模型。

系統理論過程分析（SPTA）方法主要流程是：事故→系統控制結構→不安全控制行為→原因分析→安全約束。

進行STPA分析時，其分析過程包括駕駛員職責劃分（R-x），對應的控制行為、對應的反饋等幾個部分。

其中駕駛職責主要是指決策何時剎車，何時啟動：是手動還是自動？其中涉及駐車、啟動指令，汽車物理結構反饋（速度、剎車踏板狀態、油門踏板狀態）、外部環境反饋（位移）、視覺位移、AutoHold開關狀態。

監督自動剎車/啟動過程，出現故障時手動剎車，給自動駕駛系統發送觸發信號等幾個部分。

STPA的方法仍舊是不夠完美的，在將其直接應用于高等級自動駕駛上時，還需要解決自動駕駛汽車事故數據記錄問題，體現不同功能下的車輛狀態控制結構差異；以系統的方法來分析具體失效原因。

3、NOA下的SOTIF分析實例

我們知道對于以自動駕駛為基礎的安全能力分析主要包括從整體場景抽象，從感知端、規劃控制到決策執行端的整個分析過程。對于很多設計功能來講，都需要基于已有的分析和經驗積累，形成預期功能安全場景庫，便于識別所有觸發條件。

首先在系統輸入層面，需要定義設計運行范圍ODD（定義中包含特殊天氣場景、特殊交通流場景），場景抽象完成后再進行策略設計，策略設計主要是為了滿足動態駕駛任務的設計過程，涉及利用NOP對應的系統硬件架構對周邊環境進行的感知、提取交通流下的關鍵場景、利用關鍵場景進行車身控制。

設計中包含整車層面、系統層面、零部件層面幾個大方面。從下至上，則包括合理可預見誤用作為觸發條件，功能不足及性能受限的說明，風險分析。

進一步細化危害行為這一模塊分析又涉及具體的危害事件描述、危害場景重建、相關人員反映、可控度、傷害（人員）、嚴重度、是否可接受等。基于如上信息又會拆解到對于該危害場景的具體觸發條件，包括場景特征（如道路特征、交通設施特征、氣候環境特征、其他特征）、主車駕駛場景（行動、事件、目標）、其他交通參與者行為、發生概率。

如下列舉幾個典型的預期功能安全場景識別與應對，作為案例分析。

實例1：誤作用識別

實例2：誤觸發條件的識別

實例3：因果關系識別

4、《自動駕駛準入指南》對于預期功能安全的要求

這里為什么要提自動駕駛準入呢？因為對于車企來講，肯定希望自身所開發設計的功能能夠在量產上市前得到工信部、公安部、交通部等部門的認可，拿到正常的牌照上市，這也算是可以正身（也就我們所說的量產上市準入）。這樣的需求就需要在整個設計、研發及驗證期間做到設計強有力的預期功能安全管理流程，將安全文化滲透到企業的方方面面，在各個環節中進行Documentation Work，對產品的生命周期進行監控。

而具體涉及到其開發的車型產品方面，就要求參考國際、國內標準的開發流程，在產品開發環節做必要的SOTIF分析。通過仿真、實車測試手段對產品的SOTIF能力進行驗證，在產品使用中仍繼續對SOTIF能力進行迭代。

預期功能安全的開發流程要求可以確保企業在設計定義、危害識別、功能不足識別、功能改進、驗證及確認、安全發布、運行維護等方面得到最好的規范，保障車輛不存在因為前期功能設計不足可能導致的較大風險。

首先預期功能安全規范和設計的要求通過相關項定義識別和評估預期功能可能造成的危害，這類危害主要涉及失效后的整車級危害以及結合場景形成的危害事件。

如上這類失效危害需要評估危害造成的風險，制定合理的風險可接受準則。通常對于已知危害場景中的問題，即S>0且C>0的危害事件，在進行了功能修改后，若仍不能使S=0或C=0，則需適當調整風險可接受準則（作為驗證目標的依據），作為該危害場景下的驗收標準。接收標準涉及幾個重要的參量：

單位里程（或單位時間）內危害行為事件的平均發生次數，該參量實際關系發生頻次，這里以α表示；危害行為事件發生的平均里程或時間間隔（即無事故里程或時長）β；發生失效的置信度水平，該參量實際關系對于失效場景的判斷是否準確τ。最終我們可以定義對于當無危害行為事件里程數達到一定值β時，具有一定置信度水平η的情況下，可認為該系統在同等駕駛從場景危害事故率能達到要求的觸發頻次數α。

那么這里我們的風險接受準則條件可以以如下公式可以表示三者之間的關系：

其次，預期功能安全要求識別和評估潛在功能不足和觸發條件（含可合理預見的人員誤用），并應用功能改進等措施減少預期功能安全相關的風險。

這類風險減緩措施實際是通過ODD分析、事故場景數據分析、安全分析方法來識別功能不足和導致危害事件的觸發條件，具體到相應的危害場景。

此外，預期功能安全還要求定義驗證及確認策略，并進行預期功能安全的驗證和確認，評估已知危害場景和未知危害場景下是否符合產品預期功能安全發布要求，并對發布后產品的預期功能安全風險進行合理管控。

最后，需要重點定義駕駛自動化系統預期功能安全相關零部件的接口要求，確保零部件符合對應的預期功能安全設計開發、驗證、確認等規定。

針對這一開發過程企業需要從哪些方面努力還能真正在預期功能安全上做到很好的開發能力呢？

鑒于目前相當一部分車企在預期功能安全上的研發精力投入還遠遠不夠，因此，企業應該首先建立并維持良好的Safty Culture，鼓勵企業內部各部門就預期功能安全問題展開溝通和研究（包括感知、決策、執行系統的元件升級設計規范和評估報告等），并根據企業自身特點，建立合理的安全異常解決機制。鼓勵OEM與供應商在預期功能安全開發中一同制定開發接口協議DIA，明確開發要求，并在開發過程中對DIA進行多次分階段討論、打和。

同時，安全管理流程上帝的有效完善也是必不可少的。這其中就包括提供質量管理體系的證明材料，對安全管理人員提出合理的的Competence考核辦法，以確保勝任相關工作，對Safety Plan、Safety Case和Safety Confirmation等文件中所涉及的內容詳細記錄在案。

此外，在生產開發流程上，需要建立產品的后開發流程，包括關于產品的生產、運營、維護、使用等安全管理計劃，提供生產現場的審查報告等。

寫在最后 ?

預期功能安全分析中的關鍵技術主要是指HARA、FTA、FMEA、HAZOP、STPA等幾個方面，這幾個方面也是與功能安全分析相重疊的部分。本文以NOA為例，在我們對設計過程中，需要參照以下步驟進行詳細分析分解。