ISO 26262

此章節列出了在應用標準中的詞語、定義和縮寫（專案詞彙表）[1] 特別重要的是對於「故障」（fault）、「錯誤」（error）及「失效」（failure）的定義，因為這些詞語是此標準定義功能安全流程的關鍵[3]，特別是故障可能會放大，成為錯誤，而錯誤最終可能會導致失效[1]。所產生「誤動作」（malfunction）會造成「危害」，也就表示失去安全功能。

項目（item）

此標準中，「項目」是關鍵的詞語。項目是指可以適用ISO 26262安全生命週期，在車輛層級實現某機能（或某機能的部份）的特定系統（或系統組合）。「項目」是在此流程中最高的識別對象，也是此標準下，特定產品安全開發的起點

單元（element）

一個系統、一個元件（其中包括硬體零件，也可能包括軟體單元）、單一的硬體零件或單一的軟體單元（software unit），也就是系統中可以獨立識別以及使用的部份

故障（Fault）

會讓單元或是項目無法使用的異常條件

錯誤（Error）

有關計算到、觀察到或量測到的值或是條件，和真實的、規範的或理論正確的值或是條件之間的差異

失效（Failure）

說明一個單元或是項目因為故障影響而沒有預期行為的情形

容錯（Fault Tolerance）

在有一個故障或是多個故障的情形下，可以實現所規範機能的能力

誤動作行為（Malfunctioning Behaviour）

相對於項目的設計預期，項目的失效或是非預期行為

危害（Hazard）

因為項目誤動作行為，可能會造成損害（harm，身體受傷或健康受損）的潛在來源

機能安全（Functional Safety）

沒有因為電機／電子系統的誤動作行為，而造成不合理危害的風險

ISO 26262:2011版和其他的機能安全標準不同，也和2018年改版後的內容不同。ISO 26262:2011沒有明確定到容錯，因為其中假定不可能理解系統內的所有故障[4]

ISO 26262沒有使用IEC 61508中的「安全失效分數」（Safe failure fraction），改用「單點故障度量」（single point faults metric）和「潛在故障度量」（latent faults metric）[5]。

ISO 26262提供汽車應用的功能安全標準，定義整個組織的安全管理標準，以及針對車用產品開發和生產安全生命週期的標準[6][7][8][9]。下一章敘述的ISO 26262安全生命週期是以此處列出的安全管理概念來運作[1]：

危害事件（Hazardous Event）

危害事件是指車輛層級的危害以及車輛運作條件的組合，而且若駕駛沒有及時採取行動，可能會造成事故的事件

安全目標（Safety Goal）

安全目標是指指定為系統的最上層安全需求，目的是要降低一個或多個危害事件的風險，到可以容許的程度

車輛安全完整性等級（Automotive Safety Integrity Level）

車輛安全完整性等級（ASIL）代表特定車輛針對某一安全目標，以風險為基礎的分類，也包括標準中為了達到此一目標，需要有的驗證和確認

安全需求（Safety Requirement）

安全需求包括了所有的安全目標，也包括從安全目標分解的所有需求，以及分配給硬體或軟體元件的所有最低級別機能以及技術安全需求

ISO 26262安全生命週期中的程序會識別及評估危害（安全風險）、為了降低風險到可允許的程度，建立對應的安全需求、針對安全需求進行管理和追蹤，產出合理的保證資料，說明在產品中已實現這些安全需求。安全相關的流程可能會整合到傳統的品質系統需求生命週期，也可能會和此系統並行[10][11]：

1. 識別項目（item，特定的車用系統產品），以及定義其最上層的系統功能需求。
2. 識別項目的全面風險事件（hazardous events）
3. 針對一個風險事件，定義其ASIL（可參考Part 9）
4. 針對風險事件決定其安全目標（safety goal），其中也包括風險事件的ASIL。
5. 針對汽車層級的功能安全概念（functional safety concept），定義可以確保安全目標的系統架構。
6. 將安全目標再拆解為細部的安全需求（safety requirements）
   （一般而言，每一個安全需求都會使用上層安全需求或安全目標的ASIL。不過因為實際情形的限制，可能會將一個安全需求拆解為數個ASIL較低，但有冗餘機能的安全需求，由獨立的冗餘元件來實現）。
7. 安全需求會分配到各架構組件（architectural components），可能是子系統、硬體組件、軟體組件
   （一般而言，每一個組件都需要考慮分配到安全需求的ASIL等級，依其標準和程序進行，若有多個等級，以最高的為準）
8. 依分配的安全需求以及機能需求開發架構組件，並且確認符合對應需求。

ISO 26262中有定義一些在安全生命週期中在各階段都持續進行的支持性流程，這個是整合性的流程，也提供了為了支持通用流程目標需額外考慮的事項。

• 受控制的企業介面，可以下達目標、需求和控制方式給分散式開發中的所有供應商。
• 明確的標示安全需求以及在生命週期中的相關管理方式。
• 工作文檔的配置管理，有正式唯一的識別方式，可以重現配置，可以建立各工作文檔和配置變更之間的可追蹤性
• 正式的變更控制，包括變更影響的管理，目的是要確保識別到的缺陷已移除，在產品變更時不會導入危害。
• 工作文檔驗證的規劃、控制以及報告，驗證可以是評審、分析及測試，也包括各來源識別到缺陷的回歸分析。
• 計劃性的識別及管理在安全生命週期中，所有有助於機能安全以及安全評估持續管理的工程文檔（文件）
• 軟體工具（計劃使用以及實際使用的工具）的合格性審查
• 以往開發的軟體及硬體模組，要整合到目前開發ASIL等級的合格性審查
• 用服務歷史證據來證實某項目若要用在指定的ASIL等級，已有足夠的安全性。

車輛安全完整性等級（ASIL）是指針對車輛系統或是系統中元件，以其固有安全風險所作的抽象分級方式。ASIL分級會配合ISO 26262一起使用，來表示要預防某特定風險，需要降低風險的程度，ASIL D對應最高等級的風險，ASIL A則對應最輕微的風險。針對特定風險評估的ASIL等級也會指定給對應的安全目標，從這個安全目標衍生的安全需求也需要依此ASIL為準[12]。

要評定ASIL，需進行危害分析及風險評估，依其結果評定ASIL[13]。在ISO 26262中，危害是以對系統有害影響的相對影響程度為準，再考慮造成這些影響的危害是否容易出現。每一個危害事件都是以可能造成傷亡的嚴重程度，也考慮車輛暴露在此危害的相對時間長度，以及駕駛可以反應，以避免此傷亡的相對可能性來考慮[14]。

在安全生命週期的開始，會進行危害分析及風險評估，針對所有識別到的危害事件以及安全目標來評估其ASIL。

危害事件會依其可能造成的傷亡來評定其嚴重度（severity，簡稱S）：

嚴重度分類（S）

S0 無人受傷

S1 輕度到中度傷害

S2 嚴重到生命危險（可能存活）的傷害

S3 危及生命到致命的傷害

风险管理除了考慮可能傷害的嚴重性外，也會考慮傷害發生的可能程度。針對特定危害，危害事件若不太容易發生，可視為有較低的風險。在ISO 26262的危害分析及風險評估程序中，發生傷害性危害的可能性是由以下這二項的組合而成：

暴露機率（exposure，簡稱E）：可能會發生此傷害的運作條件，其相對的發生率

可控度（control，簡稱C）：駕駛可以反應，避免此傷害的可能性

暴露機率分類（E）

E0 幾乎不可能

E1 可能性非常低（只會在罕見的運作條件下會出現）

E2 可能性低

E3 可能性中等

E4 可能性高（大部份的運作條件下都會造成傷害）

可控度分類（C）

C0 一般而言可控

C1 可以簡單控制

C2 正常而言可以控制（大部份的駕駛可以反應，以避免傷害）

C3 難以控制或不可控

在上述的分類中，ASIL D的危害事故定義為可能會危及生命到致命的傷害，在大部份的運作條件下都會造成傷害，而且駕駛難以避免傷害。ASIL D結合了上述S3, E4和C3的分類。上述分類若有任何一個從其最嚴重分類往下降，都會讓ASIL等級離開ASIL D[15]（例如，假定不可控（C3），會造成重傷（S3）的危害，若發生機率非常低（E1），需分類為ASIL A）。ASIL等級中比ASIL A更低的是ASIL QM，意思是沒有安全的相關性，只需要依品管系統的要求進行即可。[13]

嚴重度、暴露機率、可控度的分類都是資訊性的，不是說明性的，因此有一些各車廠和供應商解讀的空間，也可能會造成歧義[14][16]。因此国际汽车工程师学会（SAE）提出了J2980 – Considerations for ISO26262 ASIL Hazard Classification，提供了特定危害下，較明確可以評估嚴重度、暴露機率、可控度的指南[17] 。