安全分析在汽車系統工程中的重要性

瞭解 ISO 26262 功能安全標準，以及汽車製造商在符合這些標準時所面臨的挑戰。

多年來，汽車安全一直是原始設備製造商 (OEM) 優先考量的重點。自動駕駛車輛、先進駕駛輔助系統 (ADAS)，以及由 AI 驅動、以進一步確保我們行車安全的創新科技正在快速發展。

這是一段令人雀躍的旅程，但對於汽車製造商來說，一路上不乏有些小插曲。舉例來說，根據《富比士》雜誌的報導，2023 年與汽車軟體相關的召回事件從 13% 躍升至 42%。而其中只有少數 (13%) 可透過無線更新方式來解決。不幸的是，這種趨勢預計將持續到 2025 年以後。

召回對 OEM 來說，是既昂貴又不可避免的行動，目的是為了維護品牌完整性，更重要的是，保護可能因相關系統潛在故障而受到影響的人。然而，隨著這些以及其他汽車安全系統日益複雜，傳統的安全驗證方法對汽車製造商來說，仍然是個重大的難題。

讓我們來看看安全分析，這是系統工程的一個重要層面。這是兩篇部落格的第一篇，重點在於安全分析與系統工程之間的關係。文中將介紹推動汽車創新的 ISO 26262 功能安全和汽車功能安全標準，以及系統工程在處理這些標準時所遇到的痛點。

稍後，我們將帶您瞭解模型式安全分析 (MBSA)，以及 Ansys medini analyze 系統導向的安全分析軟體在此流程中的運作情形。

功能安全：基本知識

功能安全是安全主題的一個關鍵子課題。具體目標是降低電子系統和軟體無法正常運作所造成的風險，關注的重點在於電氣/電子 (E/E) 架構系統的安全性。因此，氣體、火災和電力等危害並不適用，而是適用於網路和實體安全等其他安全子課題。

當然，不同的產業採用不同的標準。汽車、鐵路、發電廠、醫療設備和航太等產業都有各自的功能安全標準。對於沒有特定標準的產業，則會以 IEC 61508 作為一般電子/電氣系統的規範。

ISO 26262 汽車系統工程方法

ISO 26262 與汽車產業直接相關，它將系統開發的整個生命週期，描述為確保車輛系統安全的額外附加活動，這點有別於傳統的 V 形模型開發流程，此外並明確指出在什麼時間點，由誰負責執行哪些與安全相關的活動。

如下所示的工程 V 形模型，呈現了車輛開發過程中，從初步設計、實際建造到後續系統測試的一系列步驟。圖表中的「V」形強調開發階段是與測試階段平行進行的。

ISO 26262 汽車開發流程 V 形模型

生命週期從 V 形模型的左上方開始 (由 OEM 啟動)，經過 V 形模型的中間部分 (由供應商負責)，然後到 V 形模型的右上方。每個階段都以 V 形排列，在初始階段 (左側) 定義的需求，會在 V 形相同高度的最終階段 (右側) 進行驗證。

在確定適當的 ASIL 等級之後，在整個汽車開發過程中，安全系統、元件和需求都必須符合指定的 ASIL。

系統工程與汽車安全的挑戰

系統工程的核心並沒有太大的改變，但其複雜性卻隨著這些系統規模呈指數成長而隨之攀升。因此，傳統方法無法處理這種複雜性。此外，這些系統的擴張和演進對發展產生了有害的影響。這些系統的快速擴張和演進，可以從自動駕駛車輛的全球銷售預測中推論出來。

具體而言，從 2019 年至 2030 年，至少具備第 3 級(Level 3)自動駕駛功能的車輛數預計將達到約 5,800 萬輛 (相比 2019 年的140 萬輛)。當然，這種快速成長的缺點，就是能否驗證和確認所有支援這種上升趨勢的系統以及系統之系統的運作完整性。

以下是工程師採用傳統的系統工程方法來處理汽車安全問題時，所遇到的一些特定問題：

• 資訊重複。相同的資訊出現在不同的文件中。
• 資訊分散。相關資訊分散在不同的文件中。
• 缺乏一致性。資訊不一致。
• 無法追蹤。沒有可用的中繼資訊。例如，不瞭解為何要新增變更，也不清楚變更由誰委託、何時實施，或是否對變更進行了深入分析，這些都是相當常見的情況。
• 高度依賴特定的少數員工。難以分享/傳遞經驗給同仁，會減緩進度，並在團隊之間造成知識落差。

功能安全是各種製造業面臨的重要課題，尤其是汽車業。這是由於車輛系統甚為複雜，以及上路後系統發生故障的後果相當嚴重。在看似不確定的情況中，有一件事是肯定的：在需要符合產業法規和國際標準方面，傳統的系統工程方法已不敷使用。

進一步瞭解 Ansys medini analyze 軟體如何協助您提升車輛安全性。