在ISO26262功能安全中，有多個地方需要進行安全分析，安全分析的質量很重要的決定了功能安全項目的成敗，本文針對ISO26262中提到的各種安全分析進行彙總說明（HARA、FMEA、FTA、FMEDA、SWFMEA、DFA）。
1. HARA
在概念階段，功能安全要求進行HARA分析。
HARA（危害分析與風險評估）目的是識別項目的功能故障引起的危害，對危害事件進行分類，然後定義與之對應的安全目標，以避免不可接受的風險。
HARA分析步驟：
SEC說明：
ASIL等級說明：
QM指的是 質量管理，表示此項功能不影響安全，通過質量管理保證即可。
舉例說明：
| 危害事件 | 場景分析 | S | E | C | ASIL |
| EPS按照非預期的方向轉向 | 在城市道路，車輛正常勻速行駛（E4），車輛方向按照非預期轉向，此時駕駛員很難控制(C3)，道路兩邊人員較多，可能造成路人或者駕駛員的傷亡(S3) | 3 | 4 | 3 | D |
2. FMEA
在系統階段，功能安全要求針對各種失效模式進行分析。
FMEA是一種自下而上的歸納分析方法，用於識別系統失效(failure)，找出失效原因(Fault)，以及分析失效影響(Effect)。
分析步驟（典型七步法）：
（參考：http://www.ts16949rz.org/fmeapx/2395.html）
目前新版的使用AP值代替了原來的RPN方法，以下進行說明。
SOD說明：
AP說明：
| AP | H | M | L |
| 說明 | 高優先級，表示需有必要措施（shall），以改進預防或探測控制 | 中優先級，應有必要的措施（should），以改進預防或探測控制 | 低優先級，可有(could)措施進行改進預防或探測控制 |
AP優先級定義：
典型FMEA表格（新老版的）：
3. FTA
在系統階段，ISO26262還要求進行FTA（故障樹分析）；
FTA是一種自上而下的演繹分析方法，用於識別失效原因及失效間的關係，目前針對FTA也只是做定性分析。
分析步驟：
1. 確定頂事件，一般爲在整車角度描述的影響到安全目標的事件，如針對EPS，頂事件可定義爲非駕駛員意圖的轉向，針對MCU，頂事件可定義爲非預期的加速等。
2. 分解中間事件，針對頂事件，根據系統組成或特點，進行分解，系統外界以及系統內部一般都需要考慮在內。
3.基本事件，中間事件繼續向下分析，得到無法再分解的事件，他們是組成系統頂事件失效的根本原因。
常用的符號：
典型FTA圖：
4.FMEDA
在硬件設計階段，ISO26262要求進行定量的安全分析。
由於功能安全標準中已有對其進行較爲詳細的介紹，本文更多的是從中進行彙總摘要。
故障類別：
失效分析過程：
失效率：
λS P F — — —與硬件要素單點故障相關聯的失效率;
λRF — — —與硬件要素殘餘故障相關聯的失效率;
λMPF— — —與硬件要素多點故障相關聯的失效率;
λS — — —與硬件要素安全故障相關聯的失效率。
單點故障度量：
潛伏故障度量：
總體計算過程：
5. SWFMEA
在軟件階段，ISO26262要求對軟件架構進行安全分析，此處也是定性分析。
SWFMEA分析的目的在於找出影響到功能安全的軟件失效，從而可以增加探測或診斷覆蓋來提高系統的安全。
SWFMEA，分析過程可參考系統FMEA，只是這裏的分析對象略有差異，以下針對差異進行說明。
SWFMEA，主要針對架構元素進行分析，如針對接口，分析其傳入的參數的異常情況、錯誤調用接口情況等；針對函數，分析其傳參的異常情況、調度的異常情況（沒調用、調用過快、過慢等）、數據的一致性分析、資源消耗異常等情況。
安全機制的覆蓋度，可參考ISO26262標準附錄。
6.DFA
DFA指的是相關性分析，ISO26262要求從三個層面（系統、硬件、軟件）分析，找出系統中的共因以及級聯失效。
若系統進行了ASIL分解，則DFA必須分析，以此作爲系統分解後的證據。
級聯失效：
任一失效，系統都會失效；
共因失效：
失效後，冗餘措施不起作用。
系統分析角度：
系統架構、系統邊界、系統人員、系統環境、系統開發生產維護等過程。
硬件分析角度：
硬件架構、硬件選型、硬件人員、供電電源等。
軟件分析角度：
CPU共享資源、軟件架構、軟件人員、軟件工具、算法方案等。