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对外的技术安全要求的假设；

如果发现假设与实际情况不匹配，则需要采取硬性分析和相应的技术变更。