ISO 26262中对独立安全要素（SEooC）的开发要求
独立安全要素的应用场景
ISO 26262针对为不同应用场景和不同客户开发的通用安全相关要素，规定了其相应的开发要求，称这种要素为独立安全要素（Safety Element out of Context-SEooC）。
顾名思义，“独立安全要素”的存在不是为了某个特定的安全相关项或为了某种车型而设立，而是针对
一套系统
一系列系统组合
子系统
软件
硬件
元器件（如ECU、MCU）
使用通讯协议的软件
汽车开放系统架构（AUTOSAR）软件等而设立。
独立安全要素的特点
与ISO26262有相应鉴定方法的复用成熟软件或是货架产品硬件不同（此类产品在开发之初不考虑ISO26262的相关系列标准），SEooC的开发过程是基于一系列安全要求假设基础上，充分按照ISO26262的标准要求进行的开发设计。
ISO26262给出了四种情况来描述不同的硬件或软件的认证状态类型，如下表所示，设计者或用户可以根据需要选择要开发或者评估相应的要素。
| 按照相关项安全要求的ISO 26262要素 | 经 ISO 26262要素评估鉴定的要素 | 独立安全要素 | 具备应用履历的要素 |
| 是否需要按照ISO 26262重新开发 | 是 | 否 | 是 | 否 |
| 复用时是否需要技术变更 | 是 | 否 | 是 | 是 |
| 复用时无需技术变更 | 否 | 是 | 是 | 是 |
独立安全要素的安全要求
在开发SEooC时，设计者往往无法从用户方得到明确的安全要求。针对这个问题，ISO26262要求在开发独立安全要素前，要进行适当的假设，假设独立安全要素可能适用的更高层级要素分配的安全要求，或者是为了配合其他同层级别要素实现安全功能而分配到的安全要求。
如何保证这些假设在相关项层面是成立的？ISO26262中规定了，在开发SEooC时进行假设需要在更高层级的相关项开发时，进行验证或评估，如：
当SEooC在与实际的相关项集成过程中，通过考量相关项对SEooC的应用要求（环境要求，功能要求，外围要求）等，对比SEooC的开发假设是否与这些要求吻合，进而确认假设是否成立，如果出现“差异”就需要进行“影响分析”：
1）如果差异不会造成违背相关项的安全目标，就认为SEooC的开发假设与实际的差异是可接受的；
2）如果差异造成了违背相关项的安全目标，但通过安全度量（硬件架构度量和随机硬件失效概率度量，点击阅读相关文章）计算满足系统目标安全等级要求，差异可接受；
3）如果差异造成了违背相关项的安全目标，而且无法满足系统安全等级要求，可以对相关项的定义或功能安全概念进行变更；
4）如果差异造成了违背相关项的安全目标，而且无法满足系统安全等级要求，又无法对相关项的定义或功能安全概念进行变更，则需要对SEooC进行变更，以适应差异带来的影响。
以MCU作为SEooC为例(MCU开发案例)
对内技术安全要求假设
安全等级假设：MCU被分得的ASIL等级要高于集成系统一个等级（ASIL）
安全机制假设：
复位时，MCU实施一个令所有I/O置低电位的操作
硬件上存在一个单独的存储保护单元用于隔离不同的ASIL软件任务
通过硬件对CPU指令存储器进行监控或纠错，保证覆盖90%指令存储故障
故障处理时间假设：任何与正在处理的功能相关安全机制要在10ms内完成
对外技术安全要求假设
系统要在MCU外围设置了过压和欠压的检测安全机制
系统要为MCU提供“看门狗”以检查MCU时序和程序顺序失效
系统要利用软件检测MCU的EDC（纠错）故障
系统在上电时利用软件对CPU程序顺序的逻辑监控故障进行诊断
系统不得使用MCU的调试接口(JTAG)
MCU实际集成到更高层级的系统或相关项时，MCU作为SEooC的相应的假设要进行逐项分析：
1）对内的技术安全要求是否能够符合系统或相关项的安全目标的要求；
2）系统或相关项的配置是否能够符合MCU对外的技术安全要求的假设；
如果发现假设与实际情况不匹配，则需要采取硬性分析和相应的技术变更。