在安全系统的设计中，有些情况下会选取既往项目开发的、商业购买或开源的软件或硬件作为安全系统的一部分，这种类型的组件不是依据功能安全标准进行开发的，缺乏按照安全生命周期V模型的过程证据，存在系统性失效和随机性失效导致功能失效的可能性，这一类组件称之为已存在组件(pre-existing items)。此类设备在安全系统的应用中有很多类型，硬件如单板计算机、工作站、服务器、交换机、路由器，软件如操作系统、协议栈、驱动程序、中间件。
以下是常用的三个功能安全标准中对已存在组件的要求：
IEC61508
在IEC61508-2 7.4.2.2中，对系统性安全完整性（系统性能力）的要求，给出了三种路线：
其中路线2说明可以采用提供设备经使用证明（proven in use）的证据，要求依据7.4.10节，其中：
7.4.10.1 对于一个组件来说，只有其具有明确限制和规定的功能，并且有足够的文件证据证明任何导向危险的系统性失效的可能性足够低，以致于使用该组件的安全功能安全完整性等级能够达到。证据应基于组件特定配置的运行经验分析，适用性分析和测试。
这一条要求已存在组件对于分配给它的安全完整性等级下，应基于组件在以往运行条件下的运行数据，在预期应用中的分析和测试，能够形成完备的文档证据。
7.4.10.2 在7.4.10.1中要求的文档证据应证明：
a)特定组件之前的使用条件与在预期应用的安全系统中将要使用的条件是一致的，或是很接近的；
b)在以前的使用中没有超出危险失效率。
这一条要求需要检查已存在组件在已有运行数据下的运行条件和将要应用的运行条件，两者是否一致，这些使用条件有运行环境、使用模式、执行的功能、配置、与其它系统的接口、操作系统、编译器和人为因素。给已存在组件分配的危险失效率，根据以往运行条件下的运行数据，危险失效率是满足要求的，这个前提是运行条件的一致性。
已存在组件的运行数据可以通过建立组件的缺陷跟踪系统来分析历史数据。
7.4.10.3 如果以上运行条件的差异分析发现有差异，需要对运行条件的差异进行影响分析，对差异产生的风险进行控制，这方面提供的信息应建立文档化的证据，在7.4.10.4条款中至少包括：
a) 针对预期应用对已存在组件进行适用性的分析和测试；
b) 证明预期运行和以往运行经验的等效性，包括对两者的区别进行影响分析；
c) 统计数据证据。
7.4.10.6 条款要求，当已存在组件中有未涉及的功能，不应对所使用组件的功能安全完整性产生不利影响。如通过物理或电气方式禁用相应功能；将未使用的软件排除在运行配置外；或者其它形式的论据或证据。比如使用的COTS操作系统，在编译时关闭不使用的软件功能，禁用未使用的协议和通信端口。
7.4.10.7条款要求，应用过程中已存在组件产生的变更按照IEC61508的变更管理要求来管理。
ISO26262
在ISO26262-8中，第14章规定了已现场应用，没有完整的功能安全过程证据的组件，通过在用证明(proven in use)的方式对相关项/要素进行复用，在用证明要素的类型有系统、功能、硬件或软件，或某个过程的工作成果。
使用在用证明目的在于：
-
a) 将已商业使用的“汽车应用”部分或全部沿用到另一个应用；或
-
b) 使运行中的电控单元增加一个功能；或
-
c) 对ISO26262标准发布前已在现场应用的组件；或
-
d) 其它行业的安全相关组件应用于汽车；或
-
e) 广泛使用的，不是特别为汽车应用开发的COTS组件。
通过组件的文档，配置管理和变更管理记录，安全相关事件的现场数据作为证明的证据。
14.4.2条款对如何用在用证明代替要素的生命周期子阶段及工作成果进行了规定，称为在用证明的可信度。
14.4.3条款要求对在用证明组件候选项进行识别，包括组件的以下信息：
-
a) 候选项的识别和可追溯，形成一个候选项内部要素或组件的目录；
-
b) 相应的配合要求、形式要求和功能要求，候选项的接口、环境特性、物理尺寸特性、功能和性能特性及；
-
c) 候选项之前使用时的安全要求及相应的ASIL等级。
14.4.4条款是对候选项变更的分析，变更包括候选项的变更和候选项环境的变更，都需要进行分析。候选项的变更分为设计的变更和实现方式的变更。设计规格的变更有需求变更，功能或性能的优化，实现过程的变更有软件修复，使用新的开发工具或生产工具。配置数据或标定数据的变更如与组件的安全目标有关，也属于候选项的变更。
候选项环境的变更有候选项用于不同安全目标或规格的新应用，候选项安装在新的目标环境（如车型、环境条件），与候选项存在相互作用的组件升级或位于候选项附近的组件升级。
在相关项及环境的变更，要素及环境的变更分析中，都要识别候选项及环境的变更。
14.4.5条款为现场数据分析的要求，包括配置管理、变更管理，ASIL安全目标值的确定，现场问题的分析。
EN50129
在EN50129-2018中，第6.2节对已存在组件（pre-existing items）应用于安全相关系统进行了说明，已存在组件不等同于在用证明组件，在用证明需要有应用于现场数据的支持，而已存在组件指已经存在的不是为当前特定项目开发的组件，缺乏质量管理和安全管理的过程证据，缺乏技术安全的证据。因此，并不是所有的已存在组件作为安全相关功能的实现主体，只有两种情况可以应用：
-
a) 按照其他安全标准开发的完整已存在系统实现一个或多个安全相关功能；
-
b) 已存在组件，仅作为安全相关功能的一部分。
第一种情况，已存在系统的所有已有证据应进行跟踪，识别的偏差项按照EN50129标准进行变更，对于不同的SIL等级，应对本标准的技术措施符合性进行评估。
第二种情况，作为完整的安全相关系统中的一部分，需要满足以下要求：
1）已存在组件的信息，包括功能、接口、硬件和/或软件限制，故障率，环境条件和其他使用条件
2）已存在组件的配置管理控制
3）识别危险的功能失效模式，采用接口危害分析的方法进行识别。或者采用FMEA的方法，但是缺乏已存在组件内部组成信息的情况下，这种方法不一定可行
4）对于识别出的危险功能失效模式，需要采用以下方法之一进行证明：
-
a) 不会由于内部架构、数据结构或固有的物理特性导致危险功能失效模式发生；
-
b) 按照分配的SIL等级，对已存在组件进行安全证明；
-
c) 已存在组件的危险失效模式在系统级检测并进入安全状态，检测时间应满足所要求的安全目标。
5）进行失效率定量计算时，采用保守的组件全部失效率；
6）已存在组件集成到系统中，所有的设计、安全验证、安全确认应将其作为黑盒处理；
7）对已存在组件的变更控制。
以上三个功能安全标准中对已存在组件的要求，对已存在组件的应用都需要组件完整的信息识别，组件的配置管理和变更控制，组件的安全目标证明，以往现场运行环境和集成到被评估系统中的差异分析。ISO26262重点对有现场应用的组件集成于安全系统提出了在用证明的要求，对组件现场运行数据的分析如何达到分配的ASIL目标的要求，EN50129重点对已存在组件的危险的功能失效模式分析提出要求。
原文始发于微信公众号（薄说安全）：已存在组件的功能安全评估
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论