單元 2 · ISO 26262 全景：12 parts 總覽

功能安全家族、ASIL、安全生命周期、關鍵術語

← 單元教學

2.1 ISO 26262 是什麼

ISO 26262「道路車輛—功能安全」（Road vehicles — Functional safety）是針對量產道路車輛（含機電/電子系統）的功能安全標準。核心精神：把風險降低到「可接受」的程度，並用證據證明。

關鍵：ISO 26262 管的是因系統失效（含隨機硬體失效與系統性失效）造成的不合理風險。它不管純機械磨損、也不管網路安全（那是 ISO/SAE 21434）。

2.2 12 parts 一覽

Part主題一句話重點
1詞彙術語與定義
2功能安全管理安全計畫、確認、安全案例
3概念階段Item 定義、HARA、安全目標
4系統層開發TSR、系統設計與驗證
5硬體層開發硬體需求、FMEDA
6軟體層開發軟體需求到驗證
7生產與營運生產、操作、維護
8支持過程CM、變更、驗證、信任度
9ASIL 導向分析分解、FMEA、FTA、DFA
10指南應用指引
11半導體指南半導體元件指引
12摩托車適用摩托車領域調整

背誦口訣：2 管理、3 概念、4 系統、5 硬體、6 軟體、7 生產、8 支持、9 分析、10–12 是指引。

2.3 安全生命週期（Safety Lifecycle）

概念→系統開發→硬體/軟體開發→生產/營運→維護/報廢
重點：安全生命週期不是一次性活動——維修/改版都要回到生命周期重新評估。

2.4 ASIL：功能安全的「強度表」

ASIL（Automotive Safety Integrity Level，汽車安全完整性等級）由 HARA 的 S/E/C 三項評級決定（詳見單元 4）。四級由低到高：

等級含義示意
QM一般品質管理即可音響、導航（無安全需求）
ASIL A輕度尾燈亮度異常
ASIL B中度儀錶警示延遲
ASIL C高度煞車輔助失效
ASIL D最高主動轉向失效
實務陷阱：ASIL 越高，要求的「證明強度」越高（覆蓋率、獨立性、安全機制冗餘）。不要只把 ASIL 當「標籤」，它直接決定工作量。

2.5 Worked Example：一個安全目標怎麼寫

範例
安全目標 SG-01（ASIL C）
「在單點煞車控制失效時，車輛應在 500 ms 內進入安全狀態
 （可控制減速至停止），且不造成無意的加速。」

來源：HARA-03（煞車失效情境，S3/E3/C1 → ASIL C）
驗證方式：故障注入測試 + 時序量測（≤ FTTI 500 ms）

動手：把你所在領域最嚴重的失效情境，寫成一個安全目標（含來源與驗證方式）。

2.6 深入原理：風險、ASIL 與生命周期的關係

ISO 26262 的核心不是替每個功能貼上最高等級，而是先確認「失效會造成什麼不合理風險」，再用 ASIL 調整工程嚴格度。ASIL 只描述方法與證據的強度，不代表功能本身必然安全；還要靠安全機制、驗證、量化分析與生產後回饋共同完成。當設計、硬體、軟體或使用情境改變，原本的安全論證也可能失效，因此變更管理必須把影響分析帶回 HARA、需求與測試。

階段主要問題可留下的證據
概念哪些情境不可接受？Item、HARA、SG
開發如何降低單點與系統性風險？FSR/TSR、架構、分析
驗證需求與安全機制真的有效嗎？測試、覆蓋率、故障注入
營運現場資料是否改變假設？事件、變更、回饋

2.7 Worked Example：一次變更如何回到生命周期

範例
變更：AEB 雷達取樣率由 30 Hz 改為 20 Hz
1. 重新計算端到端延遲與 FTTI 假設
2. 檢查 HARA 的危害情境是否仍成立
3. 更新 TSR、SWR、架構時序預算
4. 重跑故障注入與資格測試
5. 以變更單、評審紀錄與新基線封存證據

2.8 練習

  1. 從 12 parts 中挑出與「需求變更」直接相關的三個 part，說明原因。
  2. 解釋為什麼 ASIL 不是產品品質分數。
  3. 列出一項營運階段可能迫使團隊重新評估安全假設的現場訊號。
看完這單元你應該能說出：
  • 說出 ISO 26262 的 12 個 parts 各自管什麼。
  • 畫出安全生命週期的主要階段。
  • 解釋 ASIL 的用途與四個等級。

延伸閱讀

2.A 進階真實情境 Worked Example

進階範例：安全經理的日常——需求變更引發的安全影響分析
情境：Tier-1 供應商在開發中期收到 OEM 的需求變更：
  「增加自動泊車功能，車速 ≤ 10 km/h 時啟動。」

安全經理的反應流程：
┌─ Step 1：影響評估 ────────────────────────────────────────┐
│ 原 HARA 結果：泊車場景 ASIL B（S1 × E2 × C2）            │
│ 新增功能：低速自動轉向 + 環境感測融合                      │
│ 重新 HARA：                                               │
│   H-02 感測融合錯誤導致碰撞（S2 × E3 × C2）→ ASIL C       │
│   H-03 泊車路徑規劃異常（S1 × E2 × C2）→ ASIL B           │
│ 結論：新功能引入了 ASIL C 需求，需調整安全計畫。           │
├─ Step 2：計畫調整 ────────────────────────────────────────┤
│ 安全計畫更新內容：                                         │
│   • 新增安全目標 SG-02：泊車期間感測融合偏差 ≤ 10cm       │
│   • 安全分析（FMEA/FTA）重新執行                          │
│   • 設計驗證計畫增加自動泊車路徑精度測試                   │
│   • ASPICE SWE.1 追溯矩陣新增 12 條安全需求               │
├─ Step 3：溝通與確認 ──────────────────────────────────────┤
│ 安全經理需：                                               │
│   • 通知 OEM 安全影響分析結果                              │
│   • 更新 FMEA 表單並重新計算 RPN                          │
│   • 確認 FTTI 在泊車場景（≤ 10 km/h）是否需要調整         │
└────────────────────────────────────────────────────────────┘

2.B 深入原理擴充

ISO 26262 Part 2 §6.4.3 明確定義「安全經理」（Safety Manager）的職責： 負責協調安全活動、追蹤安全計畫執行、管理安全相關文件變更。在 ASPICE 框架下，安全經理的角色 與 MAN.3 專案經理高度重疊——實務上常由同一人兼任，但需明確區分「專案管理」 與「安全管理」的職責邊界。

核心挑戰：需求變更管理。每當功能需求變更，安全經理必須評估： ① 是否觸發新的 HARA 情境？② 現有安全機制是否足夠？③ ASIL 等級是否需要調整？ 這個「安全影響分析」（Safety Impact Analysis）是 ISO 26262 Part 8 §9 的核心要求， 也是 ASPICE SWE.1 / SYS.2 的隱含要求。

2.C 診斷式疑難排解表

症狀可能原因解決方案
安全計畫延誤，里程碑逾期需求變更頻繁，HARA 反覆執行建立變更凍結機制（Change Freeze），在關鍵里程碑前 4 週鎖定需求
安全影響分析結果與 OEM 認知不一致HARA 假設條件未對齊與 OEM 共享 HARA 假設清單，定期對齊場景定義與暴露度參數

2.D 進階挑戰題

  1. 撰寫一份安全經理的 RACI 矩陣（Responsible/Accountable/Consulted/Informed），涵蓋 HARA、安全設計、安全驗證三個階段。
  2. 若 OEM 在量產前 2 個月提出需求變更（增加後方碰撞預警），安全經理應如何評估？列出決策流程。
  3. 比較 ISO 26262 Part 2 與 ASPICE MAN.3 在「專案計畫」要求上的異同，找出至少 3 個重疊點與 2 個差異點。
← 上一層
單元教學目錄
下一篇 →
單元 3 · ASPICE 全景：過程群組與能力等級