ISO26262針對為不同應用場景和不同客戶開發的通用安全相關要素，規定了其相應的開發要求，稱這種要素為獨立安全要素（Safety Element out of Context-SEooC）。

顧名思義，“獨立安全要素"的存在不是為了某個特定的安全相關項或為了某種車型而設立，而是針對

?一套系統

?一系列系統組合

?子系統

?軟件

?硬件

?元器件（如ECU、MCU）

?使用通訊協議的軟件

?汽車開放系統架構（AUTOSAR）軟件等而設立

與ISO26262有相應鑒定方法的復用成熟軟件或是貨架產品硬件不同（此類產品在開發之初不考慮ISO26262的相關系列標準），SEooC的開發過程是基于一系列安全要求假設基礎上，充分按照ISO26262的標準要求進行的開發設計。

ISO26262給出了四種情況來描述不同的硬件或軟件的認證狀態類型，如下表所示，設計者或用戶可以根據需要選擇要開發或者評估相應的要素。

在開發SEooC時，設計者往往無法從用戶方得到明確的安全要求。針對這個問題，ISO26262要求在開發獨立安全要素前，要進行適當的假設，假設獨立安全要素可能適用的更高層級要素分配的安全要求，或者是為了配合其他同層級別要素實現安全功能而分配到的安全要求。

如何保證這些假設在相關項層面是成立的？ISO26262中規定了，在開發SEooC時進行假設需要在更高層級的相關項開發時，進行驗證或評估，如：

當SEooC在與實際的相關項集成過程中，通過考量相關項對SEooC的應用要求（環境要求，功能要求，外圍要求）等，對比SEooC的開發假設是否與這些要求吻合，進而確認假設是否成立，如果出現“差異"就需要進行“影響分析"：

1）如果差異不會造成違背相關項的安全目標，就認為SEooC的開發假設與實際的差異是可接受的；

2）如果差異造成了違背相關項的安全目標，但通過安全度量計算滿足系統目標安全等級要求，差異可接受；

3）如果差異造成了違背相關項的安全目標，而且無法滿足系統安全等級要求，可以對相關項的定義或功能安全概念進行變更；

4）如果差異造成了違背相關項的安全目標，而且無法滿足系統安全等級要求，又無法對相關項的定義或功能安全概念進行變更，則需要對SEooC進行變更，以適應差異帶來的影響。

MCU實際集成到更高層級的系統或相關項時，MCU作為SEooC的相應的假設要進行逐項分析：

1）對內的技術安全要求是否能夠符合系統或相關項的安全目標的要求；

2）系統或相關項的配置是否能夠符合MCU對外的技術安全要求的假設；

如果發現假設與實際情況不匹配，則需要采取硬性分析和相應的技術變更。