Functional Safety
車用功能安全要求對應
車輛產業是一個不允許系統失效發生的產業，因為一發生失效車輛廠商將面臨官司賠償與商譽受損的巨大風險，為了防止系統失效的發生，必須有一套嚴謹且可靠的開發流程來讓系統開發工程師依循，以往車輛產業大部分是採用失效模式效應分析(Failure Mode and Effects Analysis, FMEA)手法來進行失效分析與預防除 FMEA 手法外，近期亦漸漸有車輛廠商將 ISO 26262 功能安全設計標準應用於失效分析與預防上，ISO 26262 標準可補足 FMEA 手法於軟體分析的不足。
ISO 26262 精神之要求
ISO 26262 為功能安全分析的嚴謹的確認制度，車輛產業系統功能安全設計分析手法的主流。目前全球之 OEM 廠、一階零組件廠、 車用晶片商、開發工具商皆已開始著手於其產品開發過程中導入 ISO 26262，或使其販售之軟硬體開發工具符合 ISO 26262 之要求，完成功能安全流程建立。ISO 26262 可使公司內部清楚定義專案展開流程與功能安全相關系統、硬體、軟體開發應共同遵循的目標，此有利於爭取加入大型跨國車輛系統開發專案，對外可清楚定義出系統所需達成之安全門檻。
車輛功能安全等級（ASIL）
ISO 26262的目標是通過避免汽車E/E 系統故障行為可能導致的危害來提高E/E系統的功能安全。ISO 26262採用車輛功能安全等級（ASIL）來判斷系統的功能安全程度， A（最低）、B、C及D（最高）四個等級組成，ASIL等級越高表示系統的功能安全評估越嚴格,相應的表示系統正確執行安全功能，或者說的避免該功能出錯的概率越高，即系統的安全可靠性越高。
基於V模式的測試週期:
ISO 26262標準的組成架構由十個規範和資訊指導檔案組成，其中ISO 26262—4/5/6闡述的是系統級/硬體級/軟體級的產品開發，使用巢狀的V模型定義了每個開發階段的過程以及相應的工作產品。
團隊在軟體級產品開發階段去理解ISO 26262的要求，在實際的軟體開發過程中結合ISO 26262的軟體測試生命週期，通過包括軟體測試工作的執行，過程控制等方面來確保ECU軟體質量，滿足ISO 26262軟體級功能安全相應等級的要求。
專案定義階段
需求分析:
此階段要分析用戶的需要，整理出系統的需求。一般而言，此階段會和用戶面談，建立用戶需求文件（user requirements document）。用戶需求文件會說明系統的功能、介面、性能、資料、安全性等，會列出客戶預期的需求。
系統設計:
此階段會列出要實現用戶需求需要的技術以及可能性。若有些用戶需求不可行，會反應給用戶，針對此需求的最後處理方式也會列在用戶需求文件中。此階段也會產生軟體規格文件（software specification document），是開發階段的藍圖，其中會包括大致的系統架構、指令選單結構、資料結構等。
架構設計:
這個階段會設計計算機系統結構及軟體架構，也稱為高階設計。選擇架構的基準是應該可以實現所有模組的列表、模組的簡單機能、介面關係、相依性、資料庫、資料庫表、架構圖、技術細節等。在這個階段也會設計整合測試的內容。
模組設計:
模組設計階段也稱為低階設計。會將設計的系統拆解為較小的單元或是模組，也會說明每一部份的內容，讓程式設計者可以直接寫程式。 低階設計文件或是程式規格書會包括模組的邏輯細節，可能會以偽代碼的方式表示，單元測試會在此階段進行規劃。
確認階段
單元測試:
在V模型中，在模組設計階段就會規劃單元測試計劃（Unit Test Plans）。單元測試計劃的目的是要消除程式碼層級及單元層級的錯誤。單元是程式中可以獨立存在的最小程式體。單元測試是驗證最小的程式體在和其他程式隔離的情形下，是否可以正常運作。
整合測試:
整合測試的計劃會在架構設計階段訂定。整合測試會驗證這些獨立創建、獨立測試過的模組是否可以共存，互相交換訊息。整合測試的測試結果常會分享給用戶的團隊。
系統測試:
計劃會在系統設計的階段訂定。系統測試不同於單元測試及整合測試。系統測試計劃會由用戶的團隊來進行。系統測試會確保所開發的軟體符合預期的需求，會測試整個軟體的機能、相互依存以及通訊。
用戶驗收測試:
計劃會在需求分析階段就訂定。測試計劃是由企業用戶來進行。用戶驗收測試會在用戶的環境下進行，設法模擬實際產品的環境，也會使用實際的數據。用戶驗收測試的目的是要確認所提供的系統符合客戶需求，而且系統已可以在實際環境下使用。
Software tools ｜ 符合 ISO 26262 之要求軟體開發工具
軟體開發工具(設計輔助工具、模擬工具、驗證工具)必須取得合格證明後方可使用於車輛功能安全計畫上。除軟硬體元件外，項目(Item)、系統(System)、功能(Function)、硬體產品(Hardware product)、軟體產品(Software product)皆可被再使用於車輛功能安全計畫上，但都必須通過嚴謹的評估流程後方可再使用。
Hardware solutions ｜ 硬體於車輛功能安全
1. 基礎硬體零件(如：電阻、電晶體…) →需取得 ISO 16750, AEC Q100, AEC Q200…等認證。
2. 硬體零件(如：解碼器、CAN 收發器…) →需取得 ISO 16750, AEC Q100, AEC Q200… 等認證，若有安全需求關聯性，則還必須遵守 ISO 26262 Part8 Clause 13 之規定。
3. 硬體元計(如：致動器、感知器、MCU…) →必須遵守 ISO 26262 Part8 Clause 13 之規 定，若有安全需求關聯性，則還必須遵守 ISO 26262 Part4 與 ISO 26262 Part5 之規定。
4. 複合硬體元件(如：ECU…)→必須遵守 ISO 26262 Part4 與 ISO 26262 Part5 之規定。