需求擷取、系統需求分析、系統架構設計
ASPICE 系統層（SYS）把「利害關係人需求」逐步變成「可驗證的系統」：
| 過程 | 輸入 | 輸出 | 關鍵活動 |
|---|---|---|---|
| SYS.1 需求擷取 | 客戶/法規/內部 | 利害關係人需求 | 蒐集、分類、優先序 |
| SYS.2 系統需求分析 | 利害關係人需求 | 系統需求規格 | 技術化、驗收準則 |
| SYS.3 系統架構設計 | 系統需求 | 系統架構設計 | 分解、介面、分配 |
利害關係人需求 SR-01（客戶） 「車輛應在市區低速時提供自動緊急煞車，避免碰撞靜止物。」 → 優先序：高 ｜ 來源：OEM 規格 ｜ 法規：E-NCAP AEB 評分項目
系統需求 SYSR-01 ｜來源 SR-01
「AEB 須在市區（車速 5–50 km/h）偵測前方 3–30 m 的靜止/移動
物體（行人、車輛），並於 TTC < 1.2 s 時輸出煞車請求。」
驗收準則：在 HIL 上以 80 個場景測試，行人偵測率 ≥ 99%，
誤觸發率 ≤ 0.1%；見測試案例 TC-SYSR-01-01…80。
SYSR-01（AEB 偵測煞車）分配：
雷達模組 → 偵測與距離量測（ASIL C(D)）
AEB ECU → TTC 判定、安全決策（ASIL D）
煞車致動器 → 執行減速（ASIL D）
CAN 匯流排 → 訊息完整性（CRC、計數器；防偽訊）
介面契約：目標清單物件格式（固定 32 位元組 frame）
雷達心跳 50 ms；ECU 監控逾時 → 進入安全狀態。
動手：為你的系統畫一張架構圖，並把 3 條系統需求分配給元件。
SYS.1 的原始聲音通常包含目標、限制與期待；SYS.2 必須把它整理成單一、可測量、可測試的系統需求；SYS.3 再將需求分配給元件與介面。分配不是把文字複製到不同文件，而是確認每個責任都有 owner，跨元件行為有介面契約，安全需求有 ASIL 與故障反應。任何無法分配的需求，都是架構或需求分析尚未完成的訊號。
| 追問 | SYS.1/SYS.2 的答案 | SYS.3 的答案 |
|---|---|---|
| 做什麼？ | 功能與驗收條件 | 哪個元件負責 |
| 何時做？ | 延遲與週期 | 排程與介面時序 |
| 失效怎麼辦？ | 安全狀態與診斷 | 監視者、隔離與備援 |
需求 SYSR-07：雷達資料錯誤時，系統不得發出自動煞車命令。 分配檢查：雷達負責 CRC/計數器；ECU 負責有效性判定； 通訊層負責錯誤回報；致動器負責拒絕非法命令。 若只有「ECU 會檢查」而沒有介面旗標、逾時與測試 owner， SYS.3 尚未完成，因為需求沒有形成可驗證的端到端契約。
評審時可從一條 TSR 反向走到客戶需求，再向下走到元件與測試。任一方向走不通，就代表系統分析、架構分配或追溯尚未閉合。
軟體單元：車速計算模組（Vehicle Speed Calculation） ASIL 等級：ASIL D（直接影響 AEB、ESC 等安全功能） 軟體架構設計： ┌────────────────────────────────────────────────────────────┐ │ 車速計算模組（ASIL D） │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 輸入處理 │→│ 濾波演算法│→│ 輸出驗證 │ │ │ │ (輪速脈衝│ │ (卡爾曼 │ │ (合理性 │ │ │ │ 解碼) │ │ 濾波器) │ │ 檢查) │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ↑ │ │ │ ┌────┴───────────────────────────────┴────┐ │ │ │ 安全機制：輸出範圍驗證 │ │ │ │ 車速範圍：0 ~ 300 km/h │ │ │ │ 變化率限制：≤ 20 km/h per 10ms │ │ │ │ 異常值 → 使用最後有效值 + 降級模式 │ │ │ └─────────────────────────────────────────┘ │ └────────────────────────────────────────────────────────────┘ 靜態分析結果（MISRA C:2012）： 必須遵循（Mandatory）：0 違規 強制遵循（Required）：23 違規 → 修正後 0 違規 建議遵循（Advisory）：47 違規 → 接受並記錄理由 MISRA 違規分佈： Rule 11.3（指標轉型）：15 處 → 改用安全轉型函式 Rule 14.4（布林運算）：5 處 → 改用明確比較 Rule 8.7（函式/物件作用域）：3 處 → 調整為模組內部 軟體單元測試覆蓋率： 行覆蓋率（Statement Coverage）：100% ✓ 分支覆蓋率（Branch Coverage）：100% ✓ MC/DC 覆蓋率：98.7%（剩餘 1.3% 為 defensive programming 分支）
ISO 26262 Part 6 §9 要求「軟體單元測試」必須達到與 ASIL 等級對應的覆蓋率。 ASIL D 要求 MC/DC（Modified Condition/Decision Coverage），這是所有覆蓋率準則中最嚴格的—— 每個布林條件都必須獨立影響判斷結果。
關鍵概念：MC/DC 的實務挑戰。MISRA C:2012 的 defensive programming 模式
（如 if (ptr != NULL && ptr->valid)）會產生 MC/DC 無法覆蓋的分支。
ISO 26262 允許在「defensive programming」分支上豁免 MC/DC，但必須記錄理由並經 Safety Review 確認。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| MC/DC 覆蓋率無法達到 100% | defensive programming 分支無法獨立觸發 | 記錄為 defensive programming 豁免，經 Safety Review 確認 |
| MISRA 違規修正引入新 Bug | 自動修正工具未考慮業務邏輯 | 所有 MISRA 修正需人工審查，並執行迴歸測試 |
| 靜態分析報告與實際編碼不一致 | 分析工具版本或配置不同 | 統一工具版本（如 Polyspace R2023b）並鎖定 MISRA 配置檔 |