安全目標撰寫、ASIL 分解、FSR/TSR 範例
安全目標（SG）是「最高層的安全要求」。接著要把每個 SG 拆解成：
| 層級 | 名稱 | 層面 | 範例 |
|---|---|---|---|
| Item 層 | FSR（功能安全需求） | 「做什麼」 | 必須偵測行人碰撞風險 |
| 系統層 | TSR（技術安全需求） | 「怎麼做」 | 以雷達在 30 m 內偵測行人 |
| 硬體/軟體層 | HWR / SWR | 「落在哪」 | 感測器取樣 ≥ 30 Hz |
FSR-01（ASIL D）｜來源 SG-AEB-01 當前方 30 m 內出現行人且碰撞時間（TTC）< 1.2 s 時， AEB 必須啟動煞車。 FSR-02（ASIL D）｜來源 SG-AEB-01 AEB 啟動後，若行人離開路徑，必須停止煞車以避免誤煞。
TSR-01（ASIL D）｜來源 FSR-01 前雷達模組必須以 ≥ 30 Hz 輸出目標清單（含距離/相對速度/類別）， 端到端延遲 ≤ 50 ms。 TSR-02（ASIL D）｜來源 FSR-01 煞車控制單元須在收到煞車指令後 20 ms 內輸出致動命令； 若致動失敗，須在 100 ms 內報告並切換到備援路徑。 安全機制 SM-01：雷達離線偵測（心跳 50 ms），失效時 200 ms 內 進入安全狀態（關閉 AEB 並警示駕駛）。
ASIL 分解是把高 ASIL 需求拆給多個獨立元件，例如 ASIL D 拆成 ASIL C(D) + ASIL A(D)（括號保留原 ASIL 以追溯）。
| 原 ASIL | 分解組合例 |
|---|---|
| ASIL D | ASIL C(D) + ASIL A(D) |
| ASIL D | ASIL B(D) + ASIL B(D) |
| ASIL C | ASIL B(C) + ASIL A(C) |
SG-AEB-01（ASIL D）
└── FSR-01（ASIL D）｜偵測行人碰撞風險 → 啟動煞車
└── FSR-01.1（ASIL D）｜雷達感測行人（感知）
└── FSR-01.2（ASIL D）｜ECU 判定 TTC 並下指令（決策）
└── FSR-01.3（ASIL D）｜致動器執行煞車（執行）
└── TSR-01.3.1（ASIL D）｜煞車致動 ≤ 20 ms
└── TSR-01.3.2（ASIL D）｜致動失敗 100 ms 內報告
└── 分解：TSR-01.3.1 拆為 ASIL C(D) 主路 + ASIL A(D) 監視路
動手：把你單元 4 的安全目標，拆出至少 3 條 FSR 與 3 條 TSR。
SG、FSR、TSR 的差異在於抽象層與責任邊界。SG 描述必須避免的危害；FSR 描述系統應具備的安全行為，不預先綁定實作；TSR 則將行為分配到感測、計算、通訊、致動與診斷元件。每次分解都要保留完整性、時序、故障反應與驗證準則。若 TSR 只寫功能、不寫失效反應，追溯表看似完整，安全論證仍會斷裂。
| 需求層 | 必答問題 | 驗證角度 |
|---|---|---|
| SG | 要避免哪個不合理風險？ | 危害情境與安全狀態 |
| FSR | 系統必須展現什麼安全行為？ | 功能、觸發條件、反應時間 |
| TSR | 哪些元件如何共同實現？ | 介面、診斷、獨立性、故障注入 |
不良 TSR：「系統應快速偵測雷達故障並安全處理。」 可驗證 TSR：「雷達心跳連續 50 ms 未收到時，ECU 必須在 100 ms 內禁止新的自動煞車請求、記錄診斷碼 DTC-RADAR-01，並點亮警示。」 驗證：停止心跳，量測 50 ms + 100 ms 上限、輸出狀態與 DTC。
若其中一項回答為「不知道」，先不要把需求移交給實作；把缺口登錄為評審議題，指定負責人與完成條件，再重新建立基線。
元件：車用電源管理 IC（PMIC），負責 ECU 供電。 ASIL 等級：ASIL D（因為是安全關鍵 ECU 的電源） 硬體架構： ┌────────────────────────────────────────────────────────────┐ │ PMIC │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ LDO 5V │ │ Buck 3.3V│ │ LDO 1.8V │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌────┴──────────────┴──────────────┴────┐ │ │ │ 電壓監控器（Voltage Supervisor） │ │ │ │ • 過壓檢測（OVP） │ │ │ │ • 欠壓檢測（UVP） │ │ │ │ • 開路檢測（Open Load） │ │ │ └───────────────────────────────────────┘ │ │ ┌───────────────────────────────────────┐ │ │ │ 故障注入測試點 │ │ │ │ • 測試點 TP-01：LDO 輸出 │ │ │ │ • 測試點 TP-02：Buck 輸出 │ │ │ └───────────────────────────────────────┘ │ └────────────────────────────────────────────────────────────┘ 安全機制設計： SM-01：電壓窗口監控（3.1V ~ 3.5V），偏差 > 5% 觸發重置 SM-02：電流限制（Current Limit），過流 > 500mA 觸發關斷 SM-03：溫度監控，結溫 > 150°C 觸發降額 SM-04：冗餘電壓檢測（雙通道交叉驗證） FMEDA 計算： SPFM（單點故障度量）：要求 ≥ 99%（ASIL D） LFM（潛在故障度量）：要求 ≥ 90%（ASIL D） 設計達成：SPFM = 99.2%，LFM = 91.5%
ISO 26262 Part 5 §8 要求「硬體架構度量」（Hardware Architectural Metrics） 必須在硬體設計階段驗證：SPFM、LFM、PMHF（Probabilistic Metric for Hardware Failures）。 這些度量直接影響硬體的 ASIL 達標能力。
關鍵概念：故障模式與影響分析（FMEDA）是 ISO 26262 Part 5 的核心工具。 與傳統 FMEA 不同，FMEDA 聚焦於量化：每個故障模式的失效率（λ）、偵測率、 潛在故障比例。FMEDA 結果直接用於計算 SPFM/LFM，是硬體安全驗證的數學基礎。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| SPFM 未達 ASIL D 要求 | 故障偵測覆蓋率不足 | 增加冗餘偵測機制（如雙通道電壓監控），提高偵測率 |
| PMHF 超標 | 元件失效率（λ）資料不準確 | 使用 SIEMENS/Textron 等汽車級元件的失效率資料，而非商用級 |
| FMEDA 結果與實際不符 | 測試條件未模擬真實環境 | 在 -40°C ~ +150°C 溫度範圍內驗證故障注入測試 |