軟體安全需求、需求規格、雙向追溯
SWE.1 軟體需求分析：把系統需求與技術安全需求（TSR）細化成軟體需求（Software Requirements），產出軟體需求規格。這是軟體層的第一份「契約」。
| 種類 | 內容 | 範例 |
|---|---|---|
| 功能性 | 行為、演算法、狀態 | TTC 計算公式 |
| 安全（繼承） | 安全機制、安全狀態 | 雷達逾時 → 停用 AEB |
| 效能 | 時序、記憶體、CPU | 決策 ≤ 20 ms |
| 介面 | 輸入/輸出、通訊 | CAN frame 格式 |
| 品質 | 可測試性、可維護性 | 日誌格式 |
SWR-AEB-011（ASIL D）｜來源 TSR-01 「當雷達目標的 TTC 小於 1.2 秒時，本模組必須輸出 BRAKE_REQUEST = ON，並持續到 TTC 回升至 2.0 秒以上。」 驗收準則： - 以 20 組輸入向量做單元測試，TTC 計算誤差 ≤ 2 ms。 - BRAKE_REQUEST 的開啟/關閉延遲 ≤ 5 ms。
ASPICE 對 SWE.1 的 CL2/CL3 要求雙向追溯：
| 系統需求 | 軟體需求 | 測試 |
|---|---|---|
| TSR-01 | SWR-AEB-011 | UT-011…020 |
| TSR-02 | SWR-AEB-021 | UT-021…025 |
TSR-01（雷達 30Hz、端到端 50ms）→ 拆成 SWR： SWR-AEB-011 TTC 計算（含公式與閾值） ASIL D SWR-AEB-012 雷達資料解析（frame→物件） ASIL D SWR-AEB-013 心跳監控（50ms 逾時偵測） ASIL D SWR-AEB-014 安全狀態轉換（停用+警示） ASIL D SWR-AEB-015 日誌與除錯輸出 QM 檢查：每一條都有唯一 ID、來源、ASIL、驗收準則。
動手：把一個你熟悉的系統功能，寫出至少 5 條軟體需求（含屬性）。
SWE.1 不只是把 TSR 改寫成較短的句子，而是把系統責任轉成軟體可實現、可測試、可追溯的契約。需求要明確定義輸入有效性、狀態、輸出、時序、錯誤反應與資料所有權；安全需求還要說明診斷失效時的安全狀態。需求之間若有優先序或衝突，也要在規格中決定，否則實作者會自行猜測，測試也無法形成唯一預期。
| 欄位 | 範例 | 驗證方法 |
|---|---|---|
| 觸發 | TTC < 1.2 s 且資料有效 | 邊界輸入 |
| 行為 | 輸出 BRAKE_REQUEST | 需求式測試 |
| 時序 | 5 ms 內完成 | 時間戳量測 |
| 失效 | 逾時後禁止輸出 | 故障注入 |
原文：「模組應在雷達資料不正常時快速停用。」 審查問題：不正常包含 CRC 錯、逾時、物件欄位越界嗎？ 修訂：任一 frame CRC 錯、連續兩個週期未更新，或距離超範圍時， 模組須在 10 ms 內丟棄該 frame、保持 BRAKE_REQUEST=OFF， 並在 100 ms 內回報 RADAR_INVALID。 結果：SWE.1、SWE.4 與 SWE.6 對同一契約有一致預期。
需求審查的產出不只是一個批准欄位，也應包含歧義、衝突、未決假設與後續行動。把這些決策保留下來，才能避免不同工程師對同一句話做出不同實作。
SWE.1 進入設計前，需求應已完成來源確認、術語定義、可驗證性審查、ASIL 標註與下游責任分配。未決需求可以保留，但必須標示假設、風險與截止日期；把未決事項藏在聊天訊息中，會讓不同基線的實作產生不可解釋的差異。
情境：OEM 與 Tier-1 分佈式開發 ADAS 系統。 OEM 負責：系統整合、整車驗證 Tier-1 負責：ECU 硬體、感測器融合軟體 ┌─ 介面協議（Interface Agreement）──────────────────────────┐ │ 1. 硬體介面（HSI）： │ │ • 供電：12V ± 10%（ISO 7637-2 瞬態脈衝保護） │ │ • 通訊：CAN FD 5 Mbit/s（ISO 11898-1） │ │ • 診斷：UDS on CAN（ISO 14229-1） │ │ │ │ 2. 軟體介面（SSI）： │ │ • API 版本：v2.1.0（語意版本號） │ │ • 資料格式：結構化訊息（16 bytes fixed） │ │ • 錯誤處理：E2E 保護（CRC-8 + 計數器） │ │ │ │ 3. 安全介面（Safety Interface）： │ │ • 安全通訊協議：AUTOSAR E2E Profile 11 │ │ • 故障反應時間：≤ 50ms │ │ • 安全狀態：跛行模式（Limp Home） │ ├─ 驗收流程 ────────────────────────────────────────────────┤ │ 1. Tier-1 提交：安全驗收報告（Safety Validation Report） │ │ 2. OEM 審查： │ │ • HSI 完整性檢查 │ │ • 安全機制有效性驗證 │ │ • 故障注入測試結果 │ │ 3. 驗收標準： │ │ • SPFM/LFM 達標 │ │ • 所有安全測試案例 PASS │ │ • 無 Severity 1/2 的殘留問題 │ └────────────────────────────────────────────────────────────┘
ISO 26262 Part 8 §13 要求「分佈式開發介面」（Distributed Development Interfaces）。 當安全相關元件由不同組織開發時，必須建立明確的介面協議，定義：① 職責邊界、② 介面規格、 ③ 驗收標準、④ 變更管理流程。
關鍵概念：「安全驗收」（Safety Acceptance）。這不是簡單的功能測試—— 必須驗證安全機制在分佈式環境下的有效性。例如：OEM 的系統整合測試必須能覆蓋 Tier-1 提供的 ECU 的所有安全相關故障模式，即使這些故障模式在 Tier-1 的測試中已通過。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 分佈式開發的介面規格不明確 | 缺乏統一的介面規格模板 | 建立標準化的介面規格文件模板（含 HSI、SSI、Safety Interface） |
| 安全驗收測試無法覆蓋所有故障模式 | OEM 與 Tier-1 的故障模式分析未同步 | 共享 FMEA/FTA 結果，共同定義驗收測試案例 |
| 介面版本不相容導致安全功能失效 | 版本管理不嚴格，回歸測試不完整 | 實施語意版本號管理，每次升級執行完整回歸測試 |