符合 ISO 26262 標準的車用軟體自動化測試工具與服務
稽核官問一句「證據呢？」，多數團隊才發現功能安全的工作量其實集中在證據，而不是測試本身。歐特莫夫基於 V-Model 開發流程，結合 Vector PREEvision 與 VectorCAST 等領先技術經驗，協助您跨越法規門檻，確保產品符合 ISO 26262 國際標準。
從 HARA 到安全論證的 ISO 26262 功能安全工具鏈
這條鏈要解決的核心問題，是「功能安全的工作量其實集中在『證據』——稽核官問一句『證據呢？』，你答不答得出來」。做法是從 HARA 與安全分析（PREEvision）開始，經靜態分析建立乾淨的程式碼基礎，再以自動化測試把單元到 MC/DC 的覆蓋率證據補齊，最後收斂成可辯護的 Safety Case。
模型驅動的系統設計，支援 E/E 架構、需求管理、安全分析 (FMEA／FTA) 與 ISO 26262 建模，把 HARA 導出的 ASIL 目標貫穿全流程。
靜態程式碼分析，強制執行 MISRA C/C++，在開發早期就偵測潛在的安全漏洞，建立乾淨的程式碼基礎。
自動化測試工具鏈，確保單元與整合測試覆蓋率，滿足 ASIL D 對 MC/DC 的嚴格要求，並整合 WCET 最壞執行時間的時序驗證。
- HARA 導出的 ASIL 目標一路貫穿到驗證，安全需求與實作雙向追溯
- 靜態分析強制 MISRA 合規，安全漏洞在開發早期就被攔下
- ASIL D 要求的 MC/DC 覆蓋率由工具量化，覆蓋缺口看得見、補得完
- 所有工作產出收斂成 Safety Case，第三方稽核時證據拿得出來
為什麼這樣架：技術判斷與往前一步
什麼是功能安全？
隨著汽車內部的電子控制單元（ECU）、感測器和軟體越來越複雜，系統失效可能導致嚴重事故。ISO 26262 的目的就是提供一套標準化的流程，確保汽車電子系統在發生故障時，能夠將風險降低到可接受的範圍內。功能安全並不代表「設備永遠不會壞」，而是指當故障發生時，系統能進入安全狀態或減緩危害，避免對人員造成傷害。
核心功能與技術優勢
標準化流程導入
從 HARA 危害分析到 ASIL 等級判定，建立符合 ISO 26262 的完整開發流程。
V 模型全生命週期覆蓋
基於 PREEvision 與 VectorCAST，實現從需求設計到驗證確認的無縫銜接。
自動化測試與驗證
利用自動化工具確保單元測試、整合測試與故障注入測試的高效執行。
關鍵指標：ASIL 汽車安全完整性等級
ASIL 等級在 V-Model 左側透過 HARA 分析確定，將貫穿整個開發與驗證流程。不同的 ASIL 等級決定了測試的嚴謹程度與所需的安全機制。
| 等級 | 意義 | 開發要求 | 範例 |
|---|---|---|---|
| QM | 品質管理 | 依照一般品質管理流程如 IATF 16949，無需特殊安全機制 | 車窗、娛樂系統 |
| ASIL A | 最低安全等級 | 需基本的安全考量 | 後車燈 |
| ASIL B | 中等安全等級 | 需適度的安全機制 | 儀表板顯示 |
| ASIL C | 高安全等級 | 需嚴格的安全機制與冗餘設計 | 主動式巡航 ACC |
| ASIL D | 最高安全等級 | 極度嚴格，涉及生命安全，必須有備援系統 | 氣囊、煞車、轉向 |
ISO 26262 測試目的及測試方法的應用
對應 V-Model 右側驗證階段，ISO 26262 明確定義了五大測試目標及其驗證方法，確保每個 ASIL 等級的安全需求都經過完整驗證：
| 測試目標 | 測試方法 | 應用 |
|---|---|---|
| 正確實現功能安全需求 | 基於需求的測試、故障注入測試、長期測試、實際使用條件測試 | 透過基於需求的測試覆蓋驗證車輛級功能安全需求（FSR），並經由道路測試確保實際場景表現 |
| 安全機制的正確功能、精度與時序 | 性能測試（含容錯時間間隔）、長期測試、實際使用條件測試 | 驗證故障檢測與緩解機制，確保系統能在規定的故障容錯時間內（FTTI）轉換至失效安全狀態 |
| 一致且正確地實現外部介面 | 外部介面測試（靜態/動態、範圍檢查）、互通測試（運行時驗證） | 執行 FAT（功能驗收測試）驗證基本功能與通訊協定，並透過實驗車測試檢驗功能互動性 |
| 驗證安全機制失效覆蓋的有效性 | 故障注入測試、錯誤猜測測試（基於專家知識）、基於現場經驗測試、資源使用測試 | 透過主動注入故障觸發安全機制，並測試匯流排負載、傳輸延遲等分布式安全項目，以及匯流排斷線、斷電、碰撞等高層級事件的應對能力 |
| 車輛層級的穩健性水平 | 壓力測試（高負載、物理壓力）、抗干擾與強健性測試（特定環境條件）、長期測試 | 進行環境測試（包含電磁干擾 EMI、溫度、濕度等極限條件），並透過長期道路測試驗證穩健性 |
歐特莫夫的技術服務流程
功能安全的工作量集中在「證據」上。四個階段把安全生命週期收斂成可執行的推進順序，每一階段都指明產出什麼、用什麼工具、我們協助到哪裡。
安全規劃與安全需求
定義安全生命週期並確立 ASIL 目標；執行危害分析與風險評估（HARA），導出功能安全概念與技術安全概念，再以 FMEA 與故障樹分析檢視失效路徑。工具以 PREEvision 與 ALM 為主。歐特莫夫提供流程諮詢、安全計畫建立輔導、HARA 分析工作坊，以及系統級的 FMEA／FTA 分析服務。
軟體需求與測試策略
進行軟體架構設計，並以 MISRA C/C++ 與 CERT C 的規範要求搭配靜態程式碼分析建立乾淨的程式碼基礎；同時定義測試層級、測試規格與需求的雙向追溯。工具為 PC-lint Plus、vTESTstudio 與 PREEvision／ALM。我們協助軟體架構的安全性檢查、合規性輔導、需求規格撰寫與測試策略規劃。
測試設計與自動化執行
設計測試案例，涵蓋邊界值與等價類分析，以及故障注入場景；接著在單元、整合、故障注入與診斷各層執行。工具涵蓋 VectorCAST、CANoe、VT System、CANoe.DiVa、DYNA4 與持續整合平台。我們提供測試腳本開發、硬體在環台架架設，以及故障注入的執行服務。
覆蓋率、審查與安全論證
分析語句、分支與 MC/DC 覆蓋率——ASIL D 需要達到 MC/DC——並處理未覆蓋到的程式碼；審查測試結果、處理異常並執行回歸驗證。最後彙整所有工作產出，支援功能安全評估與 Safety Case 的準備，以及第三方審核的應對。
常見問題
ISO 26262 稽核最常卡在哪裡？
卡在「證據」。功能安全的工作量其實集中在證明——需求有沒有測到、覆蓋率夠不夠、安全機制有沒有驗證。本方案讓證據隨開發自然累積並可雙向追溯，稽核官問「證據呢？」時答得出來。
ASIL 等級是怎麼決定的，對測試有什麼影響？
ASIL 等級在 V-Model 左側透過 HARA 危害分析與風險評估確定，從 QM、ASIL A 到最高的 ASIL D。等級愈高，測試的嚴謹程度與所需安全機制愈嚴——例如 ASIL D 涉及生命安全（氣囊、煞車、轉向），單元測試必須達到 MC/DC 覆蓋率。
故障注入測試為什麼是必要的？
ISO 26262 要求驗證「安全機制失效覆蓋的有效性」，也就是主動注入故障來觸發安全機制，確認系統能在故障容錯時間內 (FTTI) 轉換到失效安全狀態。這是只做正常功能測試無法涵蓋的驗證目標。
功能安全是不是代表「設備永遠不會壞」？
不是。功能安全指的是當故障發生時，系統能進入安全狀態或減緩危害，避免對人員造成傷害，而不是保證元件不故障。ISO 26262 的目的就是把故障造成的風險降低到可接受範圍。