01 · EXECUTIVE SUMMARY
車用軟體研發已從「交付程式」轉向「持續證明產品可被信任」
車用軟體研發不是一部單一法規，而是由功能安全、預期功能安全、車用資安、軟體更新、AI 安全、流程能力與型式認證共同構成的合規體系。SDV、Connected Car、EV、ADAS、AI 與 OTA 讓車輛在交付後仍持續演進，也使錯誤、攻擊、資料漂移與更新失敗可能跨越整個車隊。OEM、Tier 1／2、ECU、半導體與軟體供應商都必須把需求、架構、程式、測試、弱點、變更、配置與發布連成可追溯證據鏈。最重要的管理改變，是不再於稽核前臨時蒐集文件，而是在 PLM、ALM、MBSE 與測試平台中，讓每次決策自動留下版本、責任、核准與驗證證據。
02 · BASIC FACTS
法規／標準基本資料與 2026 最新狀態
正式名稱與發布單位：ISO 26262《Road vehicles — Functional safety》、ISO 21448《Safety of the intended functionality》、ISO/PAS 8800《Safety and artificial intelligence》、ISO/SAE 21434《Cybersecurity engineering》及 ISO 24089《Software update engineering》由 ISO／SAE 體系發布；UN Regulation No. 155 與 No. 156 由 UNECE WP.29 體系發布；Automotive SPICE PAM 由 VDA QMC 維護；CRA 與 AI Act 為歐盟規則。
產品與角色：適用面向包括量產道路車輛、E/E 系統、ECU、嵌入式軟體、ADAS／ADS、更新基礎設施及安全相關 AI。直接責任通常由 OEM 承擔型式認證與上市後治理，Tier 1／2、軟體、半導體及工程服務供應商則依合約與介面提供可被整車論證引用的工作產品與證據。
| 規範 | 最新狀態（截至 2026-10-10） | 性質／適用範圍 | 強制性與時程 |
|---|---|---|---|
| ISO 26262 | Parts 1–12:2018，Published | 道路車輛 E/E 功能安全國際標準，涵蓋概念、系統、硬體、軟體、生產運行與支援流程。 | 非強制法規；常由 OEM 合約、安全論證或供應鏈要求。 |
| ISO 21448 | 2022 Edition 1，Published；ISO 顯示將修訂 | SOTIF 國際標準，處理無故障但感知、規格或性能不足所造成的風險，特別關聯 ADAS／ADS。 | 非強制法規；依產品安全目標與客戶要求採用。 |
| ISO/PAS 8800 | 2024 Edition 1，Published PAS；ISO/AWI 8800-1、-2 制定中 | 量產道路車輛安全相關 AI／ML 系統的安全論證。 | 非強制法規；PAS 是公開可用規範，未來 ISO 8800 系列仍在發展。 |
| ISO/SAE 21434 | 2021 Edition 1，Published；ISO 顯示將修訂 | 車用 Cybersecurity Engineering 全生命週期國際標準。 | 非法律，但常用來支撐 UN R155 的工程流程與證據。 |
| ISO 24089 | 2023 Edition 1，Published | 軟體更新工程，涵蓋組織、專案、基礎設施、車輛／系統與更新包。 | 非法律；可支撐安全更新與 UN R156／SUMS。 |
| UN R155／R156 | 原始版於 2021-01-22 生效；UNECE 持續以修正案與解釋文件更新 | R155：Cybersecurity 與 CSMS；R156：軟體更新與 SUMS 的型式認證法規。 | 在採用的 UNECE 締約市場，依車種、修正系列與國家過渡期強制；EU 另以 2019/2144、2018/858 及其修法落實，特定小量／特殊用途車另有至 2026 的過渡時程。 |
| Automotive SPICE | PAM 4.0（2023）；VDA 2026 指南已引用 PAM 4.1 | 軟體與系統研發流程能力評估模型。 | 非強制法規；多由 OEM 採購與供應商品質要求驅動。 |
| EU CRA | EU Regulation 2024/2847 | 具數位元素產品的水平資安法律；適用 Regulation (EU) 2019/2144 的車輛產品不受 CRA 核心資安要求與合格評定程序重複規範，未被部門法規涵蓋的獨立數位產品仍需另行判定。 | 事件／已利用弱點通報自 2026-09-11；主要義務自 2027-12-11。 |
| EU AI Act | Regulation (EU) 2024/1689；2026 起分階段執行 | 風險分級 AI 法律；車用 AI 是否高風險須看是否為受管制產品安全元件及合格評定條件。 | 透明度規則自 2026-08-02；嵌入受管制實體產品的高風險規則依官方現行時程至 2028-08-02。 |
市場差異
R155／R156 在採用市場直接影響型式認證。CRA 明確避免與 Regulation (EU) 2019/2144 涵蓋的車輛產品重複規範；AI Act 仍須依 AI 功能、產品角色及合格評定條件判定。
臺灣 VSCC 對照資料已列出「網路安全及網路安全管理系統」與 UN R155；實際適用仍應依車種、基準版本、申請日期及主管機關公告確認。
NHTSA 車用資安最佳實務屬 non-binding guidance；FMVSS、缺陷與召回責任仍具法律效力，企業也須留意州法、隱私與採購要求。
03 · WHY NOW
規範出現的背景：軟體已成為車輛風險、功能與營收的核心
傳統 ECU 專案常把軟體視為零組件交付物：需求定版、開發測試、燒錄量產，車輛交付後只有少量維修更新。如今集中式 E/E 架構、高效能運算平台、雲端服務與 OTA 使功能能在上市後持續變更；一項共享函式庫漏洞、配置錯誤或模型退化，可能同時影響多車型、多地區與大量在役車輛。
過去以 Word、Excel、電子郵件與部門檔案伺服器為主的工作方式，無法穩定回答「這段程式滿足哪一項安全目標」「這個更新包適用哪些 VIN 與 ECU 組合」「供應商變更後哪些測試要重跑」。SDV 加速發布頻率，Connected Car 擴大攻擊面，EV 增加電池與能源控制複雜度，ADAS／ADS 則帶入感知限制、場景覆蓋與 AI 模型證據。規範因此逐步從開發階段延伸到組織治理、供應鏈、量產、營運監控、弱點處理與退役。
04 · CORE REQUIREMENTS
十項企業真正需要落地的核心能力
1. Governance
要求：明確政策、角色、獨立性與升級機制。
行動：建立 Safety／Cybersecurity／Software Update／AI 治理與 RACI。
Evidence：政策、能力矩陣、任命、評審與管理審查紀錄。
2. Risk Management
要求：識別故障、功能不足、威脅與 AI 不確定性。
行動：整合 HARA、TARA、SOTIF 場景與 AI 危害分析。
Evidence：風險清冊、假設、評分、處置與殘餘風險核准。
3. Requirement Management
要求：需求正確、可測試、版本受控且雙向追溯。
行動：把法規條款轉成合規需求，再分配到系統、硬體與軟體。
Evidence：需求基線、追溯矩陣、審查紀錄與變更歷史。
4. Architecture & Interface
要求：責任分解、自由干擾、介面與失效行為可證明。
行動：以 MBSE 管理功能、邏輯、軟體、硬體與通訊架構。
Evidence：模型版本、介面契約、安全機制與分配決策。
5. Development Quality
要求：程式設計、模型、工具與第三方元件受控。
行動：定義 coding guideline、靜態分析、SBOM、開源審查與工具資格策略。
Evidence：程式審查、分析報告、SBOM、建置紀錄與偏差核准。
6. Verification & Validation
要求：證明需求被滿足，未知場景與邊界條件被探索。
行動：建立 MIL／SIL／HIL／車測與場景式驗證，追蹤覆蓋率。
Evidence：測試規格、環境版本、結果、缺陷與覆蓋報告。
7. Configuration & Release
要求：任何交付都能重建並對應車輛配置。
行動：建立來源、模型、參數、二進位、校正與更新包基線。
Evidence：BoM／SBOM、manifest、簽章、release note 與核准紀錄。
8. Change & Impact
要求：變更前辨識安全、資安、法規與測試影響。
行動：將 issue、change、affected item、test 與 release 串成閉環。
Evidence：影響分析、CCB 決議、重測清單與差異報告。
9. Supplier Management
要求：分散式開發仍保持責任、介面與證據一致。
行動：以 DIA／Cybersecurity Interface Agreement、SOW 與品質閘門管理交付。
Evidence：供應商評估、介面協議、交付基線與偏差處理。
10. Post-market Monitoring
要求：上市後監控事件、弱點、模型／場景漂移與更新成效。
行動：連接車隊遙測、SOC、缺陷、召回與 OTA campaign。
Evidence：監控報告、事件通報、修補時程、更新成功率與結案證據。
05 · LIFECYCLE IMPACT
產品開發生命週期受到哪些影響
| 階段 | 主要影響與控制重點 | 關鍵輸出 |
|---|---|---|
| Concept | 界定 item、功能、ODD、使用情境、誤用、資產、法規市場與供應鏈邊界。 | Item Definition、適用性矩陣、初步 HARA／TARA／SOTIF 分析。 |
| Requirement | 把安全、資安、更新與 AI 目標分解為可驗證需求，建立雙向追溯。 | Safety／Cybersecurity Goals、合規需求庫、需求基線。 |
| System Design | 分配功能與安全機制，定義診斷、降級、更新、金鑰、時間與介面策略。 | 系統架構、介面契約、技術安全／資安概念。 |
| HW／SW Development | 控制工具鏈、編碼、模型、元件來源、AI 資料與訓練版本；確保可重建。 | 詳細設計、程式、SBOM、模型卡、建置與分析報告。 |
| Verification | 對每項需求執行靜態、單元、整合、介面與故障注入測試。 | 測試規格、測試結果、覆蓋率與缺陷處置。 |
| Validation | 在目標環境、場景與 ODD 證明車輛層安全與預期功能，確認殘餘風險可接受。 | 車輛驗證、場景覆蓋、Safety／Cybersecurity Case。 |
| Production | 確保燒錄、金鑰、序號、版本、校正與 End-of-Line 測試符合核准基線。 | 生產配置、EOL 測試、偏差與放行紀錄。 |
| Release | 確認完整性、簽章、相容性、法規市場、VIN 目標、回復與發布門檻。 | Release Baseline、更新包、release note、核准與 SUMS 證據。 |
| Operation | 持續偵測安全事件、資安威脅、現場故障與 AI／場景漂移。 | 車隊監控、SOC／事件紀錄、現場資料與通報。 |
| Maintenance | 進行弱點修補、變更影響分析、回歸測試與 OTA campaign 控制。 | 修補版、影響分析、更新結果、回滾與關閉證據。 |
| End of Life | 定義支援終止、憑證／金鑰退役、資料保留、最後安全狀態與客戶通知。 | EOL Plan、通知、停服與證據保存紀錄。 |
06 · DELIVERABLES
必須被版本控制與追溯的主要交付文件
| 交付物 | 用途 | 責任角色 | 產生階段 | 版本控制 | 追溯 |
|---|---|---|---|---|---|
| Compliance／Safety／Cybersecurity Plan | 定義適用規範、活動、角色與里程碑 | Compliance、Safety、CS Manager | Concept | 是 | 對規範與專案 |
| HARA／TARA／SOTIF／AI Risk Assessment | 識別危害、威脅、功能不足與 AI 風險 | Safety、Cybersecurity、AI Safety | Concept–Design | 是 | 對目標、需求與場景 |
| Requirements Baseline | 保存產品、系統、硬體與軟體需求 | Product Owner、System／SW Lead | Requirement | 是 | 雙向 |
| Architecture／Interface Specification | 描述分解、分配、介面與安全機制 | System／HW／SW Architect | System Design | 是 | 對需求、元件與測試 |
| Traceability Matrix | 證明條款、需求、設計與驗證完整 | Requirement／Quality | 全週期 | 是 | 核心交付物 |
| Test Specification／Report | 定義方法並保存結果、環境、覆蓋與異常 | Verification／Validation | V&V | 是 | 對需求、版本與缺陷 |
| Safety／Cybersecurity Case | 以主張—論據—證據說明風險已合理控制 | Safety／CS Manager | Validation–Release | 是 | 對所有支撐證據 |
| Review／Approval Record | 保存決策、獨立性、意見與關閉狀態 | 各 Work Product Owner | 全週期 | 是 | 對被審查基線 |
| Issue／Change Record | 管理問題、影響、任務、重測與核准 | CCB、Quality、Engineering | 全週期 | 是 | 對受影響物件 |
| Release／Software Update Record | 定義內容、相容性、目標、部署與回復 | Configuration／Release Manager | Release–Operation | 是 | 對建置、測試與車輛配置 |
| Audit Evidence Package | 提供型式認證、客戶評估與內外部稽核 | Compliance／Quality | Gate／Audit | 是 | 對適用要求與核准版 |
07 · RELATIONSHIP MAP
與其他汽車法規／標準的關係
| 標準／法規 | 關係與重疊處 | 主要差異 | 可共用 Evidence |
|---|---|---|---|
| ISO 26262 | 安全生命週期、需求、架構、V&V、配置與變更。 | 聚焦 E/E 故障造成的功能安全風險。 | 需求、架構、測試、配置、Safety Case。 |
| ISO 21448 | ADAS／ADS 的場景、觸發條件、驗證與運行監控。 | 處理無故障但功能或感知性能不足。 | 場景庫、ODD、V&V、現場監控。 |
| ISO/PAS 8800 | AI 安全生命週期、資料、模型、評估與安全論證。 | 聚焦 AI 元件輸出不足與 AI 特有不確定性；目前為 PAS。 | AI requirement、data/model lineage、metrics、Safety Case。 |
| ISO/SAE 21434／UN R155 | TARA、資安需求、驗證、供應鏈與上市後監控。 | 21434 是工程標準；R155 是適用市場的型式認證法規與 CSMS 要求。 | TARA、CS plan、測試、事件與供應商證據。 |
| ISO 24089／UN R156 | 更新包、相容性、車輛配置、部署、回復與紀錄。 | 24089 是工程標準；R156 是 SUMS 與車型更新的型式認證法規。 | manifest、release、相容性、測試與 campaign 紀錄。 |
| Automotive SPICE | 需求、架構、開發、測試、專案與支援流程能力。 | 評估「流程能力」，不直接證明產品已達安全或型式認證。 | 工作產品、評審、追溯、配置、問題與變更。 |
| MISRA／AUTOSAR | 程式品質、介面、架構與工具鏈。 | MISRA 是程式設計指南；AUTOSAR 是車用軟體架構、介面、方法與交換格式，不是型式認證。 | 靜態分析、deviation、ARXML、介面與配置。 |
| ISO 3450x | ADS 場景分類、ODD、評估與測試案例生成。 | 聚焦自動駕駛場景式安全評估；不取代功能安全、資安或 AI 安全。 | 場景庫、ODD、測試案例、覆蓋與結果。 |
| CRA／EU AI Act | 安全開發、風險、技術文件、監控、事件與供應鏈。 | 屬 EU 法律且有特定範圍與時程；不能假設 ISO 證書自動等於法律合規。 | 風險、技術檔案、SBOM、測試、監控與通報紀錄。 |
08 · RESPONSIBILITY
OEM、Tier 1、Tier 2 與技術供應者分別要做什麼
OEM
判定市場法規與車型範圍；營運 CSMS／SUMS；定義 item、整車安全／資安／更新策略；整合供應商證據；管理車隊監控、事件、召回與型式認證。
Tier 1
把 OEM 目標轉成系統與 ECU 需求；完成架構、HARA／TARA 支援、軟硬體整合與驗證；管理下層供應商並交付可被整車論證引用的證據。
Tier 2
遵循介面與安全／資安需求；提供元件限制、FMEDA／安全手冊、SBOM、弱點資訊、測試與變更通知；確保版本與適用配置清楚。
Software Supplier
管理來源、相依套件、SBOM、弱點、編碼規則、CI/CD、可重建建置與發布簽章；針對安全相關軟體提供需求到測試追溯。
Semiconductor Supplier
提供 Safety Manual、FMEDA、硬體安全機制、資安能力、勘誤、生命週期與供應狀態；及時通知影響多個 ECU 的矽晶或韌體問題。
Engineering Service Provider
依客戶邊界執行分析、模型、開發或 V&V；工具、人員能力與交付版本須受控，並確保證據所有權、保密與可移交。
09 · PLM / ALM / MBSE
系統管理的核心：一條跨工具、但不複製責任的數位證據鏈
| 系統能力 | 應負責的主資料 | 關鍵整合鍵 |
|---|---|---|
| PLM | 產品型號、BOM、零件、文件、ECR／ECO、有效性、車型與發布基線。 | Part／Document ID、Product Configuration、Change、Release。 |
| ALM | 軟體需求、backlog、程式版本、build、缺陷、CI/CD 與軟體 release。 | Requirement ID、Commit、Build、Issue、Software Version。 |
| MBSE | 需求、功能、邏輯／實體架構、介面、行為、參數與驗證案例。 | Model Element ID、Interface、Allocation、Variant。 |
| Requirement Management | 法規、合規、產品、系統與元件需求及其基線與審查。 | Global Requirement ID、Baseline、Status。 |
| Test Management | 測試案例、環境、資料集、執行、結果、覆蓋率與缺陷。 | Test Case／Run ID、Environment、Build、Result。 |
| Configuration Management | 軟硬體、模型、校正、工具、資料集、二進位、SBOM 與 update package 基線。 | Configuration ID、Hash、Signature、VIN／ECU applicability。 |
設計原則是「主資料留在最適合的系統，關聯與狀態可跨系統查證」。不要把所有檔案搬到同一處；應建立穩定 ID、事件同步、基線快照與不可否認的核准紀錄，讓稽核者能沿著關聯找到原始證據。
10 · TRACEABILITY EXAMPLE
實際追溯範例：從軟體更新要求到已發布版本
完整追溯讓稽核者能確認要求由何而來、由誰實作、在哪個環境驗證及進入哪個發布版；認證團隊可抽取一致證據，而不必人工比對檔名。當 ECU 型號、manifest 規則或法規版本改變時，Change Impact Analysis 能立即找出受影響的需求、測試與在役 campaign，避免只重測「看起來相關」的部分。
11 · COMMON FAILURES
十二項常見導入問題
需求散落
Excel／Word／Email 各自保存，沒有唯一 ID 與核准基線。
法規版本不明
只存 PDF，沒有適用市場、修訂、解釋文件與生效日。
追溯只為稽核
在專案尾端手工補矩陣，內容與真實開發不同步。
Evidence 找不到
結果存在個人目錄，缺少工具、環境、輸入資料與被測版本。
供應商版本不一致
交付件沒有 baseline、hash、SBOM、相容性與變更通知。
變更後不知重測範圍
需求、架構、程式、測試與 release 沒有關聯。
軟體發布與產品脫節
ALM 的 build 無法對應 PLM 的車型、BOM、ECU 與有效性。
把 ASPICE 當產品安全證書
流程能力良好不等於安全風險已被充分控制。
只做開發、不做營運
缺少漏洞、事件、車隊資料、AI 漂移與 OTA 成效監控。
AI 資料與模型不可重建
沒有資料來源、標註、訓練程式、超參數與模型版本譜系。
工具串接等於流程整合
介面上線但責任、狀態語意、錯誤處理與核准規則未定義。
稽核前人工蒐集
大量截圖與壓縮檔難以證明時間、版本、完整性及核准關係。
12 · ROADMAP
企業導入 Roadmap
Gap Analysis
盤點市場、車型、功能、標準、現況流程與工具。產出：適用性矩陣、成熟度與風險優先清單。
Process Definition
定義 Safety／CS／SUMS／AI／ASPICE 共用流程、RACI 與 gate。產出：流程圖、模板、責任與例外機制。
Requirement Library
建立法規條款、解釋、合規需求與重用規則。產出：受控需求庫、版本與市場 applicability。
Traceability
定義物件類型、關係、完整性規則與報表。產出：資訊模型、最小追溯鏈與缺口儀表板。
Tool Integration
以 ID、API、事件與基線連接 PLM、ALM、MBSE、測試與 CI/CD。產出：整合架構、主資料責任與監控。
Pilot Project
選一個 ECU／ADAS 功能端到端驗證。產出：可稽核 evidence package、指標、問題與改善清單。
Compliance Audit
執行內部預審、供應商證據檢查與管理審查。產出：稽核報告、CAPA、發布決策與擴展計畫。
13 · EXECUTIVE FOCUS
管理層最應該關注的五件事
市場准入
不是只問產品能不能做，而是能否用完整證據在目標市場上市與持續更新。
責任邊界
OEM 與供應商必須對風險、證據、弱點和變更通知有書面界面。
可重建發布
每一個車載版本都要能回到來源、工具、參數、測試與核准基線。
上市後能力
預算要涵蓋監控、通報、修補、OTA 與長期證據保存，而非只到 SOP。
數位證據鏈
工具投資的 KPI 應是追溯完整率、影響分析時間與稽核取證時間，而非上線帳號數。
14 · CONCLUSION
優先因應者與下一步
最需要優先因應的是計畫進入 EU／UNECE 市場的 OEM、提供連網 ECU／ADAS／OTA／AI 功能的 Tier 1 與軟體供應商，以及其關鍵 Tier 2、半導體與工程服務夥伴。不導入系統化治理，風險不只是不通過稽核，還包括型式認證延誤、漏洞通報逾期、更新錯配、召回範圍無法界定、供應商責任爭議與 Safety／Cybersecurity Case 無法成立。
建議下一步不是立即更換所有工具，而是選定一項高風險功能：確認適用市場與規範、建立條款到 release 的最小追溯鏈、量測證據缺口與變更分析時間，再決定 PLM、ALM、MBSE、測試及 CI/CD 的整合優先序。當證據在日常流程中自然形成，合規才會從專案負擔轉為縮短交付、降低重工與提升供應鏈信任的工程能力。
15 · SEO / GEO / AEO
搜尋與 AI 引用資訊
SEO Title
車用軟體研發合規指南｜ISO 26262、R155/R156、ASPICE 與 AI 安全
Meta Description
完整解析車用軟體研發的功能安全、SOTIF、Cybersecurity、OTA、AI 安全與 Automotive SPICE，說明 OEM、供應商及 PLM、ALM、MBSE 團隊的流程、證據與追溯實務。
10 個主要關鍵字
10 個長尾關鍵字
FAQ／AI 搜尋可引用簡答
不是。它是功能安全國際標準，但常成為 OEM 合約、安全論證與供應鏈稽核的必要基礎。
UN R155 是採用國家的型式認證法規；ISO/SAE 21434 是用來落實車用資安工程活動與證據的國際標準。
SUMS 讓更新版本、相容性、目標車輛、部署條件、回復與結果能被系統化控制及稽核。
通常不夠。還需評估 ISO 21448 的功能不足、ISO/PAS 8800 的 AI 特有風險、資安及市場法規。
PLM 管產品配置與發布，ALM 管軟體開發與缺陷，MBSE 管系統架構；以共同 ID 與基線形成跨工具追溯。
OFFICIAL SOURCES
官方參考來源
- ISO：ISO 26262 Road vehicles — Functional safety package
- ISO：ISO 21448:2022 Safety of the intended functionality
- ISO：ISO/PAS 8800:2024 Safety and artificial intelligence
- ISO/TC 22/SC 32：ISO 8800 系列與車用資安工作項目
- ISO：ISO/SAE 21434:2021 Cybersecurity engineering
- ISO：ISO 24089:2023 Software update engineering
- UNECE：UN Regulation No. 155
- UNECE：UN Regulation No. 156
- VDA QMC：Automotive SPICE Process Assessment Model 4.0
- AUTOSAR：Classic、Adaptive 與 Foundation 標準
- ISO：ISO 34502:2022 scenario-based safety evaluation
- EUR-Lex：Cyber Resilience Act 正式法規與車用產品範圍
- European Commission：Cyber Resilience Act 2026 通報義務
- European Commission：EU AI Act 實施時程
- NHTSA：Cybersecurity Best Practices for Modern Vehicles（non-binding guidance）
- 財團法人車輛安全審驗中心（VSCC）：臺灣車輛型式安全審驗與基準公告
本文為產業與系統治理研究，不構成法律、認證或個別產品合規意見。專案應以目標市場主管機關、最新正式文本、認證機構與客戶合約為準。