以下文章来源于AUTO世代 ，作者AUTO GENERATION
在功能安全开发过程中，很多时候我们会遇到独立于环境的安全要素开发(Safety Element out of Context, SEooC)，很多朋友搞不清:
- 什么是SEooC，
- 什么时候应用SEooC
- SEooC和正常功能安全开发有什么不同
- SEooC应该怎么开发
这篇我们就以问答的形式，专门聊聊SEooC，回答朋友们的疑问。
Q: 是什么SEooC?
SEooC是独立于具体项目背景进行功能安全要素的开发。
所谓的独立于项目背景最简单的理解就是没有具体的车辆应用背景，车辆具体参数不清楚。
需要特别注意的是，SEooC开发的安全要素可以是一个系统，软件，硬件，但不可以是一个相关项，因为相关项总是需要用于批量生产的整车环境。如果SEooC是一个系统，而该系统不是在整车环境中开发的，那么它就不是一个相关项。
Q: 什么时候需要应用SEooC?
SEooC主要有两个应用背景:
1 通用产品的开发
汽车供应商为不同的客户和不同的应用开发通用的要素。这些通用的产品是独立于不同的组织开发出来的，便于后续应用到不同组织的产品中去。
2 前期技术储备
说白了就是很多企业在产品开发前期没有具体项目，这时候必须依托内部资源进行样机或Demo开发，以便拿到OEM项目等，然后再根据具体项目进行适配型更改，这种情况也属于SEooC开发。
在这两种情况下，需要根据开发的安全要素，先对其做出关于需求以及设计的假定，这些假定包括了通过更高设计层级以及要素外部设计而得到的分配到要素的安全要求，然后根据这些假定进行功能安全开发。
Q: SEooC和正常的功能安全开发有什么不同?
从开发流程，工作输出产物的角度讲，SEooC和正常的功能安全开发并没有本质区别，只是SEooC只执行安全要素所涉及的功能安全开发阶段的流程和工作输出产物。
具体而言:
1 正常功能安全
有具体项目背景，功能安全开发始于相关项的定义，然后依次经过概念，系统，硬件，软件阶段等完整的功能安全开发过程。
2 SEooC开发
依据开发的安全要素的不同级别(是系统，软件，还是硬件)，直接进入所对应的功能安全开发阶段(系统开发，软件开发，硬件开发)，其前提输入条件，一般是上一个开发阶段的核心工作输出产物，包括前期需求，外部设计等，直接进行假设即可，然后以此为基础进行安全要素的开发。
即: 如果SEooC开发的安全要素是系统，则功能安全开发活动始于系统阶段开发。如果安全要素是软/硬件，则功能安全开发活动始于软/硬件开发。
需要注意的是，所谓的假设输入，不仅包含了上个开发阶段中和安全要素相关的安全需求，还包括了对于SEooC外部设计的假设，下图表示了假设与SEooC开发之间的关系。而SEooC本身的需求是由由假设的高级别需求和假设的该SEooC外部设计而派生出来的，它的正确实施将在SEooC开发过程中得到验证。
Q: SEooC应该怎么开发？
SEooC开发的安全要素有三大类，即: 系统，软件，硬件。26262-10:2018第9部分，对其开发过程分别进行了阐述，总体而言，就是对安全要素对应开发阶段的上个开发阶段核心相关的工作范围和产物进行考虑，并对其进行假设，作为SEooC开发的前提输入。
那么接下来我们就以这三大类安全要素为例，介绍其SEooC开发过程。
- 安全要素: 系统
系统是SEooC能够开发的最大的或者最上层的安全要素，SEooC系统开发直接始于系统阶段的开发，其上个开发阶段为概念阶段，主要的工作产物包括相关项定义，安全目标及功能安全需求，所以需要对这些内容进行假设，作为系统SEooC开发前提输入。
下图为SEooC系统开发主要过程描述，较好地阐述了哪些开发阶段内容需要进行考虑。
很有朋友很疑惑那这些前提输入要怎么假设？
一般来说，有两个途径:
- 相关类似项目内容的裁剪，由此导出概念阶段中和安全要素相关的相关项定义，安全目标和功能安全需求，然后根据SEooC系统安全要素进行适应性调整和更改。
- 如果没有相关类似项目，则可对SEooC系统应用范围进行假设，然后进行简化的概念阶段开发，主要是对系统所应用的相关项进行定义，依据系统实现的功能进行安全分析导出和其相关的安全目标和功能安全需求。
- 安全要素: 硬件
SEooC硬件开发直接对应ISO 26262-5:2018硬件开发阶段，其前提输入为和硬件相关的技术安全需求，在ISO 26262-10:2018中，对硬件SEooC所对应的技术安全需求并没有强制性要求，可以根据需要进行假设即可，或者直接定义硬件安全需求。具体开发流程及涵盖的内容如下图所示，在此不再赘述。
同样，硬件相关技术安全需求或者硬件安全需求应该怎么假设呢？
相对来讲，硬件相关的安全需求假设是SEooC安全要素中最简单的，最简单的办法就是按照ISO 26262-5:2018附件E中的内容进行对比，例如传感器，控制单元，CPU等，找出SEooC硬件相关的失效模式，对应的安全机制等，然后依此定义硬件安全需求即可。
此外，本身包含的组件种类也比较固定，硬件安全需求多可以直接复用。
- 安全要素: 软件
软件SEooC开发，大致流程和硬件SEooC开发基本一致，需要对软件相关的技术安全需求进行假设，然后以此为基础进行软件SEooC开发，具体就流程和开发范围如下图所示。
同样，软件相关技术安全需求或者软件安全需求应该怎么假设呢？
软件相关技术安全需求根据具体软件应用对象的不同，相对差异化较大，在其假设过程中，需要首先明确软件软件应用范围，是一个完整的软件组件还是会应用到具体的软件架构中等，具体需要实现哪些功能和特性。
如果前期对软件组件功能实现不够清楚，可以从软件组件输入和输出接口入手，首先假设信号相关的功能安全需求及对应的ASIL等级，软件的安全状态，FTTI等作为前提输入，然后对软件组件进行进一步安全分析，得到具体的SEooC软件安全需求即可，然后以此为基础，进行软件SEooC架构，实现的具体开发。
但需要注意的是，不管是哪种安全要素对应的SEooC开发，最后都会集成到一或多个特定应用环境，即相关项中，此时需要根据具体应用环境情况，对前提输入假设进行验证，以保证能够实现特定应用环境对安全要素的功能安全需求。
最后，需要注意SEooC要素，尤其由SEooC开发的软件和硬件组件和ISO 26262-8:2018 中第12部分软件和第13部分描述的硬件组件的鉴定和评估的区别:
1 SEooC要素开发
基于假设进行开发，整个开发过程基于ISO 26262开发过程，符合功能安全开发标准，目的在于复用多个相关项中，只需要根据特定相关项对其假设进行验证，如果存在差异则进行相应的更改。
2 软件和硬件组件鉴定
其应用背景是去复用没有按照ISO 26262流程开发的软件或硬件组件，需要对其进行鉴定，并提供证据这些组件能够满足功能安全需求。
写在最后:
功能安全SEooC开发小专题相关内容我们就聊完了，希望能够给朋友们更好地理解功能安全，推动功能安全落地带来帮助。
作者： AUTO GENERATION
文章来源：AUTO世代
推荐阅读
- 从底层软件开发角度解析NVIDIA的典型架构开发框架
- 自动驾驶软硬件解耦：理想丰满，现实骨感
- 英伟达系列芯片自动驾驶开发：硬件电源设计
- 低速容错CAN的容错机制介绍
- 智驾系统的设计瓶颈之：电源管理设计中的功能安全和状态机
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
