1 技術安全方案 (Technical Safety Concept - TSC)

• 技術安全方案 (Technical Safety Concept - TSC)

  • 是什么： TSRs 在更高層次技術實現上的頂層設計方案，屬于系統階段圍繞TSR開發的工作內容匯總，形成的系統化工作輸出結果。它描述了如何通過技術手段（硬件、軟件、系統結構）來滿足TSRs。TSC 是系統安全架構設計的主要輸入之一。如下圖：
    

  • 核心：

    • 識別和定義所需的關鍵安全機制（SM）。
    • 描述這些安全機制在系統層面如何協同工作以實現安全目標。
    • 描述系統元素（硬件、軟件模塊、外部設備）之間為確保安全所需進行的交互。
    • 初步考慮故障檢測、處理流程和安全狀態實現路徑。
    • 目標： 將分散的TSRs 整合為一個連貫的、技術可行的實現藍圖。

  • 特點：

    • 比TSR更抽象（尚未細化到具體硬件選型或軟件實現）。
    • 側重于技術策略和邏輯關系。
    • 定義了系統層面的安全行為邏輯。

  • 示例：

2 系統安全架構設計 (System Safety Architecture Design)

• 系統安全架構設計 (System Safety Architecture Design)

  • 是什么： 基于TSC，定義系統的物理或邏輯結構，明確各組件/元素及其接口，并分配功能和安全要求（包括TSRs）到這些元素。它是系統設計藍圖，特別關注滿足安全要求所需的架構特性。

  • 關鍵活動：

    • 分解系統： 識別系統的邏輯和/或物理元素（ECUs、傳感器、執行器、軟件分區、硬件模塊）。
    • 定義接口： 明確定義元素之間的交互接口（信號、協議、時序要求），包括安全相關信息的傳輸。
    • 分配安全要求： 將TSC中定義的策略和TSRs 細化并分配到具體的系統元素和接口上。
    • 實現安全機制： 設計架構以支持TSC中定義的安全機制（如冗余通道、監控單元、分區隔離）。
    • 實現： 定義滿足非功能性TSRs（如FTTI, DC）的架構手段（如通信速率、硬件選擇、軟件調度）。
    • 獨立性/隔離： 確保關鍵元素或冗余通道在故障傳播上具有足夠的獨立性（空間/時間/因果）。
    • 要素定義： 明確每個元素的內部和外部功能、接口要求、資源需求。

  • 目標： 創建一個能夠有效實施TSC、滿足所有安全需求且可行的系統結構。

  • 示例：
    

  • 說明： 這個簡化的架構展示了制動相關元素：主制動ECU (BCU)、輪速傳感器、電子手剎ECU (EPB)、監控ECU (MON) 和CAN總線。架構體現了：

    • 傳感器輸入到BCU。
    • BCU包含主控制邏輯和安全邏輯分區（實施TSC中的雙通道策略）。
    • 監控單元獨立監控BCU和EPB的活動（看門狗），并檢查總線數據完整性（CRC）。
    • CAN總線用于通信。
    • 安全狀態指示通過儀表盤實現。

3 如何進行安全分析 (Safety Analysis)

安全分析貫穿ISO 26262開發流程的各個階段，是識別危害、定義安全目標和驗證設計方案的核心手段。主要方法：

1. 危害分析和風險評估 (Hazard Analysis and Risk Assessment - HARA):

   • 目的： 識別由系統故障行為引起的潛在危害場景，并為每個危害場景確定汽車安全完整性等級 (ASIL)。
   • 輸入： 功能描述、運行場景。
   • 輸出： 危害事件清單、安全目標 (Safety Goals - SGs) 及其ASIL等級。
   • 方法： 頭腦風暴、場景分析、FMEA/FTA啟發。

2. 故障樹分析 (Fault Tree Analysis - FTA):

   • 目的： 自頂向下 分析特定頂層事件（通常是違反安全目標）發生的根本原因組合。量化分析（可選）。
   • 輸入： 安全目標、高層系統架構。
   • 輸出： 導致頂層事件的邏輯組合路徑（最小割集）、識別系統薄弱點。
   • 作用：
     • 支持安全目標定義和ASIL分解。
     • 驗證架構設計（展示設計是否能阻止故障傳播）。
     • 確認安全機制的有效性。
   • 流程圖： FTA本身是樹狀圖，不易用線性流程圖表達邏輯。可理解為：
     • 頂事件： 違反SG（如“非預期急加速”）。
     • 中間事件： 導致頂事件的組合邏輯（AND/OR門連接）。
     • 底事件： 基本故障（傳感器失效、軟件bug、通信丟失）。
       

3. 失效模式與影響分析 (Failure Mode and Effects Analysis - FMEA):

   • 目的： 自底向上 系統地識別組件（零件、軟件模塊、接口）的所有潛在失效模式 (Failure Mode) ，分析其本地影響、對上級元素的影響，以及最終對系統或車輛層面的影響（是否能違反安全目標）。
   • 輸入： 詳細的設計信息（組件規格、接口定義）。
   • 輸出： 失效模式列表及其影響、嚴重性等級、檢測方法、改進措施（通常是安全機制）。
   • 作用：
     • 識別單點故障和潛在多點故障。
     • 推導出對安全機制的需求（特別是檢測措施）。
     • 支持設計改進，提高魯棒性。
   • 流程圖(簡化過程)：

4. 相關性失效分析 (Dependent Failure Analysis - DFA):
   • 目的： 識別可能導致冗余或多樣性安全機制同時失效的共同原因 (Common Cause) 或級聯失效 (Cascading Failures) 。
   • 類型：
     • 共因失效 (CCF): 由同一個根本原因導致多個元素同時失效（如電壓浪涌損壞多個芯片）。
     • 級聯失效： 一個元素的失效引發另一個元素的失效（如某模塊崩潰導致共享內存損壞）。
   • 作用： 確保安全機制之間以及安全機制與被監控元素之間具有足夠的獨立性。評估FTA/FMEA中可能遺漏的共同失效場景。
   • 方法： 特定方法（如CCFA - Common Cause Failure Analysis），檢查表（分析空間隔離、時間隔離、設計多樣性、環境應力等）。

總結安全分析的關系： HARA定義頂層目標和風險等級；FTA和FMEA互為補充，分別從頂向下和自底向上識別設計中的故障弱點，并指導安全機制的設置和驗證；DFA則專門應對安全機制本身可靠性的關鍵問題（獨立性）。它們共同確保系統設計能滿足安全目標。

4 技術安全需求 (TSR) 如何分配到系統架構

這是系統安全架構設計的核心活動之一。目標是清晰、無歧義地將TSRs落實到具體的系統元素上，確保每個元素的職責明確，并最終能追溯回安全目標。

1. 分配流程：

2. 關鍵步驟詳解：

   • 理解TSC和TSRs： 深刻理解技術安全方案中定義的安全策略以及每條TSR的具體內容和意圖（功能性、診斷覆蓋率、FTTI、安全狀態等）。
   • 分析架構元素： 仔細審視系統架構草案（如ECU框圖、軟件模塊劃分、總線網絡拓撲）。
   • 映射策略到元素：
     • 識別責任歸屬： 對于TSC中定義的每個安全策略或安全機制，確定由哪個（或哪幾個）系統元素主要負責實現（Implement）和/或執行（Execute）。哪個元素負責檢測到故障后觸發進入安全狀態？哪個元素負責監控？哪個元素負責執行降級操作？
       • 示例（雙通道轉向控制策略）:
         • 主通道邏輯實現 -> 主ECU軟件模塊A
         • 冗余通道邏輯實現 -> 主ECU軟件模塊B (或在獨立冗余ECU上)
         • 通道比較監控 -> 主ECU內安全監控模塊C (或獨立監控ECU)
         • 輸出驅動 & 檢測到不一致時限制輸出 -> 主ECU驅動模塊D
     • 分配TSRs： 將與該策略/機制直接相關的TSRs 分配或細化后分配到對應的元素上。
       • 示例：
         • TSR-DC1 (通道比較診斷覆蓋率≥99%) -> 分配給負責實現比較功能的模塊C (細化：模塊C需要能夠比較A和B的輸出結果，并能在XX時間內檢測到YY范圍內的差異）。
         • TSR-T1 (主通道失效切換時間≤50ms) -> 分配給模塊C (需在X ms內檢測到異常) + 模塊D (需在Y ms內執行切換和限制邏輯，且X+Y ≤ 50ms)。
   • 定義接口需求： 為了實現元素間協作執行安全功能（如傳遞監控結果、觸發安全狀態、同步冗余數據），必須在元素接口規范中明確定義安全相關的要求：
     • 需要交換哪些安全相關的信號/數據？
     • 傳輸這些信號的協議是什么？（如AUTOSAR COM、帶有CRC/Counter的PDU）
     • 時序要求（最大延遲、超時）？
     • 數據的新鮮度/有效性如何保證？（如時效管理）
     • 錯誤檢測機制？（如校驗和、信號范圍檢查）。
     • 示例：
       • 主ECU模塊A和模塊B向模塊C發送計算結果數據，接口定義：
         • 需包含CRC校驗（滿足可靠性要求）。
         • 最大傳輸延遲 ≤ 5ms（滿足總體FTTI要求的一部分）。
         • 數據需帶時間戳或序號（滿足新鮮度要求）。
       • 模塊C檢測到不一致需要通知模塊D，接口定義：
         • 高優先級中斷信號或專用快速通信通道。
         • 傳輸延遲≤ 1ms。
   • 細化TSRs： 系統級的TSRs通常比較抽象。分配到元素時需要將其細化（Decompose） 為該元素級別的、更具體、可驗證的要求。
     • 系統級TSR： 整個制動系統的非預期制動響應FTTI ≤ 150ms。
     • 細化分配到元素級：
       • 傳感器失效檢測時間（TSR-Sensor-Detect） ≤ 50ms
       • 信號處理延遲（TSR-ECU-Process） ≤ 30ms
       • 安全狀態激活延遲（TSR-ECU-Actuate） ≤ 30ms
       • CAN通信延遲（TSR-CAN-Delay） ≤ 40ms （用于監控/響應信息傳遞）
       • 驗證