1. 摘要

在汽車制造商和一級供應商避免責任的背景下，公認的技術規則作為法律要求的標準具有重要的實際意義。道路車輛電子控制單元的安全性目前主要通過 ISO 26262 的要求和流程來保障。特別是隨著道路交通自動化程度的不斷提高以及現代車輛隨之而來的復雜性，一個問題浮出水面：功能安全所追求的目標是否足以打造安全的車輛系統。目前有多項標準正在制定中。ISO 26262 的第二版涵蓋了安全功能的正確性（功能安全）。安全功能的完整性 —— 也稱為使用安全性，在 ISO WD/PAS 21448 標準草案中進行了描述。安全功能的不妥協性（網絡安全）例如在 SAE J 3061 文檔中有所體現。這些不同的標準目前相互孤立，且在相互關聯上存在不一致之處。本文展示了如何基于一個共同的元模型，將復雜電子車輛系統工程中這些迄今為止相互孤立的子任務進行整合。

2. 整體安全導向開發的流程框架

本文的主要重點在于為道路車輛電子控制單元的整體安全導向開發制定一個過程框架。這使得三個已確定且迄今為止并行推進的標準化項目能夠相互交織。為此，要將現有的異構且方向各異的開發活動（功能安全、網絡安全和使用安全）整合到一個正式的過程模型中。該過程模型基于以下大致的階段劃分：

· 概念階段

· 規范活動（下游）

· 特性保障（上游）

· 維護和運營

2.1 安全相關電子控制系統的構思

安全相關電子控制系統的構思始于在實際開發之前的一個階段對使用安全設計方面的考量。如果在這個層面上的一個粗略概念被認為總體上適合預期用途，那么實際的系統開發就會開始，同時考慮功能安全和網絡安全。圖 1 展示了系統開發概念階段中設計活動之間的關系。可以清楚地看到，雖然各個開發流程仍然具有需要按順序處理的設計方面，但在系統開發的特定點上，需要對設計方面進行同步，以便它們能夠相互協調地開發，并最終 “一致地” 組合成一個整體系統。

圖 1：系統開發概念階段中設計方面之間的關系

2.1.1 使用安全設計方面

開發安全的駕駛員輔助系統的起點是確定功能和系統規范（運行設計域，ODD）。ODD 涉及自動化系統應運行的條件。此類條件的示例包括道路類型、地理位置、清晰的車道標記、天氣條件、速度范圍、照明條件以及其他由制造商定義的系統性能標準或限制。例如，對于一個不能識別橫向交通的車輛橫向控制輔助系統，車輛制造商可以為高速公路類道路（無橫向交通）設置一個 ODD，并設計輔助系統，僅在可能的情況下允許車輛激活自動化控制系統。通過這種方式，確保 ODD 始終得到滿足。
安全輔助系統的構思先于我們從 2011 年開始所了解的 ISO 26262 中的實際系統開發。在此，會對輔助系統概念進行早期的 “預驗證”，然后實施被證明合適的輔助系統概念。其目標是實現 “穩健的” 自動化功能。使用以下設計參數：

· 將責任歸還給駕駛員

· 系統的技術改進（傳感器、執行器、控制算法）

· ODD 的限制

· 對用戶可預見誤用帶來的潛在危險的評估

2.1.2 功能安全設計方面

汽車功能安全電子控制系統開發的起點是所謂的項目定義。這是與在使用安全框架內開發的 ODD 的接觸點，或者說項目定義是與網絡安全的功能定義并行制定的。項目定義會納入危害識別和風險評估（GuR，即危害分析和風險評估，HARA）中。基于對潛在危險場景的系統識別（例如通過危害與可操作性研究，HAZOP），對相關風險進行評估（參見 ISO 26262-3）。結果是，為每種危險確定完整性等級（汽車安全完整性等級，ASIL），這些等級需要在安全相關電子控制系統的開發中實施，以避免隨機失效和系統性錯誤。為了給從業人員提供實際支持，目前已有關于進一步明確傷害嚴重程度、頻率 / 持續時間和駕駛員可控性等參數的建議。

對于在 GuR 中識別出的每個危害事件，都必須設定一個安全目標。安全目標是待開發控制系統的最高安全需求。它們產生了必要的功能安全需求，以避免每個危險事件的不可接受風險。安全目標尚未從技術角度表達。如果可以通過切換到一個或多個安全狀態來實現安全目標，則必須指定相應的安全狀態。

為了實現安全目標，功能安全概念包含安全措施，包括在安全需求中詳細描述并隨后在控制系統的架構元素中實施的安全機制（英文：Safety Measures）。功能安全概念描述了故障檢測和避免、向安全狀態的過渡、容錯機制（在這種機制下，故障不會直接導致違反安全目標，并且控制系統仍然保持在安全狀態，可能會有性能限制、降級）、故障檢測和向駕駛員發出警告，以將風險存在的持續時間（暴露參數）限制在可接受的水平（例如通過故障指示器和警告燈），以及在必要時從多個由不同功能同時生成的控制請求中選擇最合適的控制請求的仲裁邏輯。

2.1.3 網絡安全設計方面

威脅分析和風險評估（TARA）識別威脅并評估已識別威脅的風險和殘余風險。TARA 的結果指導所有后續的網絡安全活動。通過識別潛在威脅和評估已識別的威脅風險，可以將系統開發中的寶貴資源（特別是人員）導向具有最高風險潛力的威脅。威脅分析和風險評估包括兩個方面：

· 威脅分析（威脅識別）—— 確定系統或組織（利益相關者）的潛在威脅。

· 風險評估（威脅分類）—— 對特定已識別威脅相關的風險進行評估和分類。

網絡安全目標是最高的網絡安全需求，包括為待開發控制系統實現網絡安全的目標。網絡安全目標是根據 TARA 的結果確定的。一旦識別出具有最高風險潛力的威脅，就為每個具有最高風險潛力的威脅確定網絡安全目標。網絡安全目標可以針對需要避免的內容，或者與潛在威脅相反的內容來指定。例如，如果潛在威脅是 “惡意干預車輛橫向控制”，則針對該潛在威脅的網絡安全目標可以表述為 “避免或防止惡意干預車輛橫向控制”。一個潛在威脅可能有多個網絡安全目標，多個潛在威脅可能有相同的網絡安全目標。網絡安全目標和相關風險用于確定實現系統網絡安全的總體策略。

網絡安全概念描述了為所考慮的控制系統維護網絡安全的總體策略。此時，網絡安全概念可能包含在 TARA 期間確定的總體網絡安全目標、與每個網絡安全目標相關的風險以及實現網絡安全目標的潛在高層策略。實現網絡安全目標的策略可能取決于與網絡安全目標相關的威脅的潛在風險潛力。在接下來的開發階段，即系統級產品開發中，網絡安全概念將被分解為具體的技術措施并加以細化。

2.2 安全相關電子控制系統的規范

在概念階段之后，將細化大致的要求，并將其分解為技術解決方案概念。結果是形成所考慮控制系統的硬件和軟件的詳細規范。

2.2.1 使用安全設計方面

使用安全設計活動不會隨著概念階段的結束而結束。如果在系統開發的后續階段從使用安全的角度提出未解決的問題，則會相應地調整概念階段的成果。從這個意義上說，從使用安全考慮得出的要求會在迭代方法中逐步細化或修正。

2.2.2 功能安全設計方面

技術安全需求應根據概念階段確定的功能安全概念以及初步的架構假設來制定。這里需要考慮例如外部接口，如通信和用戶接口、任何限制，如環境條件或功能限制以及系統配置要求。安全機制扮演著特殊的角色。這包括指定控制系統對影響安全目標實現的刺激的反應。這包括故障和相關的刺激組合，同時考慮不同的操作模式和系統狀態。
技術安全需求應在技術安全概念的框架內分配給架構元素。在此，技術安全需求被完整、可追溯地分解到硬件和軟件。此外，還記錄了同步硬件和軟件開發所需的要求（所謂的硬件 - 軟件接口，HSI）。

2.2.3 網絡安全設計方面

在概念階段定義了網絡安全概念。在規范階段，基于在系統級進行的漏洞分析對網絡安全概念進行分析，以識別在外部未授權訪問方面最易受攻擊的系統功能。這種分析以及對具有高網絡安全優先級的功能和數據的確定，用于創建技術網絡安全概念。網絡安全概念定義了在系統級為保護這些高優先級功能和數據而在網絡安全設計方面做出的具體技術決策。示例包括：

· 某些功能的隔離。例如，特定功能的計算是否應在單獨的電路中進行？

· 對策的使用（例如加密、解密）。

· 不在系統中存儲當前 GPS 位置的副本。

· 深度防御策略（英文：“Defense in depth”）。

2.3 安全相關電子控制系統的特性保障

一般來說，測試應在開發生命周期的不同時間點由不同的人員進行。原則上，測試由具備專業資質的人員進行時效果最佳。這些人員應獨立于開發團隊，且不得參與待測試系統的構思、構建和運行。原則上，必須采用可重復的測試方法，該方法可在每次系統更改時重新使用。不同設計方面的具體測試方法差異很大。

所有三個設計方面都需要獨立評估。這應該以伴隨開發的評估形式進行，如圖 2 所示。在此過程中，對階段性工作成果（工作產品）進行評估，并在過程協議中記錄未解決的問題。未解決的問題會在開發過程中重新審議，并在開發取得進展時予以解決。在系統開發結束時未解決的 “未解決問題” 將以應用條件的形式傳遞給生命周期的下一個集成階段。圖 3 示例性地展示了對于汽車安全相關電子控制系統的審批決策，需要對所有三個設計方面進行綜合的證據收集。

圖 2：伴隨開發的評估方法模型

圖 3：安全檔案（ISO 26262）與網絡安全檔案（SAE J 3061）之間的關系

2.3.1 使用安全設計方面

在使用安全的特性保障框架內，必須證明：a. 已知 / 不安全的系統狀態得到控制（驗證）；b. 未知 / 不安全的系統狀態在實際應用中不會以足夠的置信度發生。這在驗證和確認的框架內進行：

SOTIF 驗證：必須對系統和組件（傳感器、算法和執行器）進行驗證，以證明它們在已知的不安全場景（從早期分析中得出）中按預期運行，并且它們得到了充分的測試覆蓋。在此使用有針對性的基于需求的測試、車輛集成測試和故障注入測試。

SOTIF 確認：必須對系統和組件（傳感器、決策算法和執行器）進行確認，以證明它們在實際應用中不會造成不可接受的風險。

2.3.2 功能安全設計方面

為了證明功能安全，使用了各種測試方法或其組合。系統被故意推向極限，以證明它在所有環境中都能按照規范運行，或者指定的安全機制能正確發揮作用。其中包括以下測試方法：

故障注入測試使用特殊手段將故障注入系統。這可以通過特殊的測試接口或專門準備的通信設備在系統內部進行。該方法常被用于提高技術安全需求的測試覆蓋率，因為在正常運行中，安全機制通常不會被調用。

壓力測試用于檢查系統在高運行負載或高環境要求下的正常運行情況。示例包括在系統高負載下的測試，或具有極端用戶輸入或來自其他系統的請求的測試，以及在極端溫度、濕度或機械沖擊下的測試。

2.3.3 網絡安全設計方面

對于網絡安全，有多種測試方法來證明安全特性：

基于需求的測試證明技術網絡安全概念的所有要求都得到滿足和正確實施。

針對威脅的對策測試：測試用例來自攻擊樹或威脅矩陣。這些測試確保對策能有效應對所考慮的威脅。

一般漏洞測試：這種測試策略側重于使用工具或已發布的指南來發現潛在漏洞。

滲透測試：滲透測試確定對 IT 網絡、單個 IT 系統或（網絡）應用程序的攻擊潛力。為此，評估對信息網絡或單個 IT 系統進行故意攻擊的成功可能性，并據此推導出必要的補充安全措施，或者檢查已實施安全措施的有效性。

2.4 安全相關電子控制系統的生產和運營

必須有一個明確定義的流程來處理在安全相關電子控制系統中識別到的事件。有一些經過驗證的程序：來自其他行業。

事件報告：關于觀察到的網絡安全事件的報告是設計有效對策的基礎。這些報告必須詳細且及時。

對報告事件的評估：必須對收到的報告就其說服力及其對所考慮系統的潛在影響進行評估。

原因分析：在組織內不同領域專家的參與下，分析事件發生的原因。在此過程中，收集和保存關于事件的證據，并記錄從中得出的結論。

對策規劃，包括以下三個基本步驟：

· 遏制事件，防止其進一步擴散。

· 糾正事件原因，識別并專門彌補現有漏洞。

· 恢復系統，使受影響的系統恢復到可運行狀態。

監控對策的實施，確保在內容和時間上得到適當解決。
事件的后續處理，包括對所采取措施的最終文檔記錄，以及從結構上推導出未來系統技術和組織方面的改進（經驗教訓）。

2.4.1 使用安全設計方面

現場數據在使用安全設計中也發揮著重要作用。在 SOTIF 過程中，這涉及以下三個方面：

· 利用現場經驗細化危害分析。可以從現場觀察中分析事故和未遂事故的數據。從中可以推導出危險的觸發事件（“觸發事件”）。通過這種方式，現場數據支持 SOTIF 全面考慮應有功能安全性的目標。未知 / 不安全的系統狀態會及早顯現（它們變得已知 / 不安全），然后可以進行結構化的危險控制。

· 利用現場數據為 SOTIF 驗證的測試用例進行結構化推導。這涉及證明對已知 / 不安全系統狀態的完整和正確控制。

· 規劃確認，涉及證明未知 / 不安全的系統狀態也能以所需的置信度得到控制。在此，根據類似系統的現場經驗，定義測試駕駛的目標值。

2.4.2 功能安全設計方面

產品安全的判例法（特別是參見 [2]）要求汽車電子控制系統制造商采取組織措施來履行其產品觀察義務。從法律角度來看，產品觀察義務的結果使制造商能夠建立有效的危險控制（通過控制已識別危險的措施）。為此，制造商必須建立針對與其投入使用的安全相關電子控制系統有關的功能安全事件的現場監控程序。這對制造商有以下好處：

現場數據及其結構化分析有助于發現和找到功能安全的潛在問題。基于此，啟動處理這些問題的行動。

現場數據提供了經驗證據，可用于安全相關的論證（所謂的 “使用中驗證” 論證，參見 ISO 26262-8 第 14 節）。

2.4.3 網絡安全設計方面

特別是對于網絡安全，需要明確定義的流程以及通信路徑，通過這些路徑可以報告與安全相關電子控制裝置網絡安全有關的事件。這一點至關重要，因為網絡安全的威脅格局在不斷發展（例如攻擊者可用的資源），在開發時無法完全預見。網絡安全相關事件例如可以由駕駛員、監管機構（聯邦機動車運輸管理局、聯邦信息安全辦公室，BSI）、媒體或制造商報告。對于上述所有群體，都應該清晰、簡單地說明如何向制造商報告事件。隨后是對已識別事件的結構化處理（見上文）。

3. 結論和實際意義

所提出的方法為確保日益復雜的道路交通自動化功能做出了貢獻。按照 “按需而為 —— 盡可能少” 的原則，駕駛功能必須得到適當的保障。整體的保障過程體系為更高級自動化和聯網控制單元的有效市場引入做出了貢獻。通過統一建模，可以揭示不同設計方面之間的不一致之處。可以明確設計任務處理不完整的地方，或者可以提升系統開發各個子任務之間的協同效應。