接到車廠專案的團隊，遲早會同時撞上兩個名詞：客戶稽核要看 ASPICE 等級，功能安全評估要看 ISO 26262。兩邊各發一疊要求，文件看起來又有八成像——到底差在哪？要不要做兩次？
一句話分工
- ASPICE 管「你怎麼工作」：開發過程有沒有紀律、可不可重複。評的是過程能力等級（CL），由評鑑員按流程逐項打分
- ISO 26262 管「東西會不會傷人」：從危害分析（HARA）出發，把風險逐層拆成安全需求，並要求對應等級的驗證證據
一個問過程，一個問風險。不衝突，但也不能互相代替——ASPICE 等級再高，不代表功能安全成立；反過來也一樣。
攤在 V 模型上，重疊就看得見了
兩套標準都假設 V 模型式的開發：左側需求與設計、右側整合與驗證、中間要求雙向追溯。重疊的部分包括：
| 活動 | ASPICE 的說法 | ISO 26262 的說法 |
|---|---|---|
| 需求工程 | 系統／軟體需求分析 | 功能安全需求、技術安全需求 |
| 架構設計 | 系統／軟體架構設計 | 安全架構、ASIL 繼承與分解 |
| 單元驗證 | 軟體單元查證 | 單元測試＋結構覆蓋率（含 MC/DC） |
| 追溯 | 雙向追溯與一致性 | 安全需求到測試結果的完整追溯鏈 |
也就是說：同一份需求、同一次測試，兩套標準都要引用。這正是整合的機會，也是分開做的災難來源。
分開做的四個典型症狀
- 同一份內容寫兩份文件——安全需求文件與系統需求文件內容九成相同，各自維護
- 變更影響算不出來——客戶改一條需求，兩個團隊各自評估、得出不同結論，會議開到天荒地老
- 測試重跑兩次——功能安全要的證據與 ASPICE 要的查證紀錄，明明可以是同一批
- 追溯靠人工補——稽核前一個月全員停工補連結，補完下次變更又斷
整合的兩個核心動作
一、單一需求來源。 安全需求不是另一份文件，而是需求庫裡帶著 ASIL 屬性的那一群。工具上要能以屬性篩選、以基線管理變更。
二、水平追溯自動化。 V 模型左右兩側的對應關係（需求↔測試案例↔結果）由工具鏈維護，變更時影響範圍是「算出來的」，不是人工翻出來的。PREEvision 這類平台的價值就在這裡：架構、需求、安全分析在同一個資料模型裡，改一處、全鏈路看得到。
順帶一提：ASPICE 近年改版後把硬體工程也納入了流程框架，跨軟硬體的追溯需求只會更明確——越早把追溯自動化，之後越省。
下一步
如果您的團隊正同時面對客戶的 ASPICE 稽核與功能安全評估，先別急著補文件——先把生命週期接成一條。歐特莫夫（Vector Informatik 合作夥伴）協助建立單一需求來源與自動化追溯，讓兩套要求共用同一批證據。