詳細設計文件、MISRA C、defensive programming
SWE.3 軟體詳細設計與單元建置：把架構元件細化成單元（Unit）的詳細設計，再用程式碼實作。交付物：詳細設計文件 + 可編譯、可測試的程式碼。
單元：TTC_Calculator
介面：
輸入：obj_dist_m（float32）、obj_vrel_mps（float32）
輸出：ttc_ms（uint32）、valid（bool）
行為：ttc = dist / vrel；vrel < 1 m/s 時視為靜止，
設定 valid=false（不輸出 TTC）。
MISRA C 是車用 C 語言的編碼規範，用來減少系統性錯誤。常用規則：
| 規則類型 | 例子 |
|---|---|
| 型別安全 | 禁止隱含轉型（如 int→uint32 未檢查） |
| 控制流 | 禁止 goto、禁止 fall-through |
| 表達式 | 禁止副作用與未定義行為 |
| 指標 | 禁止多重指標（部分設定） |
// 不良：隱含轉型 + 未檢查除數
ttc_ms = (uint32_t)(dist / vrel);
// 改善：檢查除數 + 明確轉型
if (vrel < 1.0f) {
ttc_ms = 0u;
valid = false;
} else {
ttc_ms = (uint32_t)((dist / vrel) * 1000.0f);
valid = true;
}
// ttc_calculator.c（ASIL D）
bool ttc_calc(float dist, float vrel, uint32_t* ttc_ms, bool* valid) {
if (ttc_ms == NULL || valid == NULL) return false;
if (dist < 0.0f || dist > 200.0f) return false;
if (vrel < 0.0f || vrel > 100.0f) return false;
if (vrel < 1.0f) { // 靜止物體
*ttc_ms = 0u; *valid = false; return true;
}
*ttc_ms = (uint32_t)((dist / vrel) * 1000.0f);
*valid = true;
return true;
}
// 對應 SWR-AEB-011；SWE.4 需 UT 覆蓋（見單元 11）
動手：挑一個你程式中的函式，用 MISRA 風格 + 防禦式設計重寫，並列出你用的規則。
SWE.3 的品質不只看程式能不能編譯，也看設計是否能被審查、實作是否能被測試。防禦式設計把輸入、範圍、溢位、失敗回傳與狀態轉移明確化；編碼規範則降低未定義行為與不同編譯器解讀差異。安全相關函式應避免隱藏副作用，對錯誤採取一致策略，並讓每個防護分支都有對應測試與追溯。
| 設計檢查 | 問題 | 證據 |
|---|---|---|
| 介面 | NULL、範圍、所有權是否清楚？ | 設計規格、靜態分析 |
| 數值 | 溢位、精度、單位是否明確？ | 邊界測試、型別規則 |
| 錯誤 | 失敗後輸出與狀態是否安全？ | 故障注入、單元測試 |
風險：vrel=0 時計算 dist/vrel，可能例外或產生無效值。 設計決策：先驗證指標與範圍；vrel < 1.0 m/s 定義為靜止； 輸出 ttc_ms=0、valid=false，呼叫端不得把無效值當成碰撞時間。 測試集合：NULL、負值、最大值、0.999、1.000、正常速度， 並檢查每個結果都能對應 SWR 與詳細設計決策。
對安全函式，審查者應能從設計決策直接找到程式實作，再找到驗證案例。若只能靠作者口頭解釋，代表設計與程式的介面仍然太隱晦。
驗證目標：車速計算模組（ASIL D）的軟體獨立安全驗證。 ┌─ ISA 驗證計畫 ────────────────────────────────────────────┐ │ 1. 驗證範圍： │ │ • 軟體架構設計是否符合安全需求 │ │ • 軟體單元測試是否達到 MC/DC 覆蓋率 │ │ • 靜態分析是否遵循 MISRA C:2012 │ │ • 故障注入測試是否覆蓋所有安全機制 │ │ │ │ 2. 獨立性要求： │ │ • ISA 執行團隊 ≠ 開發團隊（組織獨立） │ │ • ISA 工具 ≠ 開發工具（工具獨立） │ │ • ISA 環境 ≠ 開發環境（環境獨立） │ │ │ │ 3. 驗證方法： │ │ • 文件審查（Design Review） │ │ • 程式碼審查（Code Review） │ │ • 測試執行（Test Execution） │ │ • 故障注入（Fault Injection） │ ├─ 執行結果 ────────────────────────────────────────────────┤ │ 1. 文件審查： │ │ • 發現 3 處需求追溯遺漏 → 已修正 │ │ • 發現 1 處安全機制覆蓋不足 → 已補強 │ │ │ │ 2. 程式碼審查： │ │ • 發現 5 處 MISRA 違規 → 已修正 │ │ • 發現 2 處效能瓶頸 → 已優化 │ │ │ │ 3. 測試執行： │ │ • 複測覆蓋率：MC/DC = 100% │ │ • 故障注入：100% 安全機制觸發成功 │ │ │ │ 4. 結論：通過 ISA，無 Severity 1/2 殘留問題 │ └────────────────────────────────────────────────────────────┘
ISO 26262 Part 8 §11 要求「獨立安全驗證」（Independent Safety Validation） 的獨立性程度取決於 ASIL 等級：ASIL D 要求最高獨立性（組織、工具、環境三重獨立）。
關鍵概念：「驗證」（Verification）vs「確認」（Validation）。 驗證回答「產品是否正確地構建？」（Are we building the product right?）， 確認回答「是否構建了正確的產品？」（Are we building the right product?）。 ISO 26262 的 ISA 是驗證——確認設計實現符合安全需求；而 ASPICE 的 SWE.4/SWE.5 則涵蓋驗證與確認兩個面向。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| ISA 獨立性不足 | 驗證團隊與開發團隊有共同 KPI | 建立獨立的 ISA 團隊組織架構，KPI 與開發團隊分離 |
| ISA 發現的問題修正後未複驗 | 缺乏修正後的複驗機制 | 所有 ISA 發現問題修正後，必須執行迴歸測試並由 ISA 團隊複驗 |
| ISA 報告格式不一致 | 缺乏統一的 ISA 報告模板 | 建立標準化的 ISA 報告模板，含發現、嚴重等級、修正狀態、複驗結果 |