图2系统设计要求规范与系统安全要求规范的关系

2一般情况下，系统设计要求规范可以包括功能级的要求和单独的硬件要求，对于复杂的系统 单独编制硬件安全要求规范。 3系统设计要求规范宜进行如图3的分解

GB/T41295.22022

图3系统设计要求规范的分解

高速标准规范范本图4过程工业SIL目标分配示例

他部件也是执行整个安全回路的必要组成部分，如安全栅、安全继电器等；其他部件不包括 执行没有直接相关的部分

GB/T41295.22022

7.2.8安全确认计划宜包含的内容见图5

图5安全确认计划内容

8.1.1需要基于系统设计要求规范开展系统（硬件）架构设计。 8.1.2对于相对简单的功能安全系统，系统架构设计可以合并到系统设计要求规范阶段实施，但单独 的软件架构设计是必要的。 3.1.3对于相对复杂的功能安全系统，宜建立单独的系统架构设计阶段。 8.1.4架构设计需要考虑GB/T20438.2一2017中7.4的适用要求。 3.1.5需要考虑对架构设计开展验证， 8.1.6需要考虑基于架构设计内容编制集成测试计划

8.2架构设计应用考虑

架构设计在保障功能安全上面需要考虑如下方面： 保证系统足够的健壮性； 保证不同模块之间适当的独立性，避免复杂的耦合关系和共因失效； 保证非安全相关模块不会对安全相关模块造成负面影响

GB/T41295.22022

8.2.2需要对架构设计的静态特性进行规范性描述（仅 ，对组成系统采构的母模块科 模块间接口进行描述。 3.2.3架构设计宜避免对每个模块内部的实现细节进行描述，这些细节是后续详细设计的内容。 8.2.4可以考虑采用多通道的MooN表决结构来实现高安全或高可用设计。可以在不同层次上实现 多通道表决，在设备层、模块层、板卡层，甚至芯片层， 8.2.5需要明确区分MooN表决结构和备用结构之间的差异，一般情况下备用结构是用于提高可用性 而非安全性。 8.2.6需要在完成架构设计验证之后，制定集成测试计划，其中包括对所有架构特性和接口特性的测 试策略

9.1.1功能安全系统设计和研发的基本要求需要考虑GB/T20438.2—2017中7.4、附录A 要求。

9.2.1随机硬件失效的要求

9.2.1.1功能安全系统最终的随机硬件失效量小于或等于第7章所规定的目标（PFDavg或PFH数 值），并通过合理的建模和计算证明该目标得以实现。 9.2.1.2随机硬件失效估算的范围是功能安全系统中所有安全相关的部分。 9.2.1.3需要考虑按照GB/T20438.6一2017中附录B开展PFDavg或PFH的估算，如果采用该方法， 确保实际的待分析系统满足规定的所有假设条件。如果采用其他方法，宜有符合数学逻辑的合理性 证明。 注：某些文献资料给出了非常简化的公式，对于简化公式的应用要更加小心，因为简化条件可能和当前实际的项目 要求不符，这会导致简化公式的错误， 9.2.1.4需要考虑使用适当的元器件失效率/失效模型数据库作为计算的输人，可以来自：

GB/T41295.22022

气特性的降额因子不宜高于67%，对于温度的降额宜不小于10℃ 9.2.1.10需要形成文档性的分析材料，以证明降额设计的合理性，宜开展测试对降额的实现情况进行 验证。

9.2.2硬件失效分析要求

2.2.1为对9.2.1所要求的随机硬件失效进行PFD/PFH估算，需要开展元器件级的硬件失效分析， 用的分析方法包括FMEDA、FTA等。 2.2.2基于元器件失效后对模块的影响以及是否能够被诊断到，失效分析宜将每种失效分类为以下 种类别之一： 可诊断到的安全失效（入SD）； 不可诊断到的安全失效（入sU）； 可诊断到的危险失效（入DD）； 不可诊断到的危险失效（入DU）； 无影响失效， 注：对于架构设计阶段已经界定为安全无关的模块，可以不对其元器件开展详细的失效分析，这些部件的失效在 GB/T20438（所有部分）中被定义为无关失效。 2.2.3对于复杂的子系统或元器件，如果其失效后安全或危险难以判定，可以将其按照50%安全 %危险的方式进行划分， 注：在一个有效的分析过程中，不宜简单的将大部分的元器件按照50%的方式划分，这会导致最终的PFDavg PFH,SFF等参数非常差，甚至连SIL1都达不到，这样的分析是没有意义的。 2.2.4需要注意区分安全失效和无影响失效，不能将无影响失效纳入安全失效之中。 2.2.5基于硬件失效分析的结论需要对已有安全设计进行复审，确保所有关键故障都得到有效控制 避免。 断包括但不限于： 诊断测试间隔过长，不满足过程安全时间的要求； 如果采用多通道设计，单纯的通道间表决不能作为单个通道内器件失效的诊断措施；

9.2.3诊断覆盖率的判定

需要仔细判断每个诊断功能的覆盖率，一般按照如下考虑进行判定 对于简单元器件，如果诊断测试能够诊断到它的某种失效模式，则该器件这种失效模式的诊断 覆盖率为100%，否则为0%，简单器件例子：电阻、电容、三极管、二极管、光耦等 对于复杂的器件，原则上基于GB/T20438.2一2017中A.1～A.14的要求。如果有更高诊断 覆盖率的申明或者采用了GB/T20438.2一2017中附录A没有规定的技术，采用测试的方法 证明所实现诊断覆盖率的真实性。复杂元器件的例子：中央处理器（CPU）、模数转换（ADC） 芯片、存储单元等。 对同一器件或模块，可使用两种或更多种诊断方法来诊断相同的失效模式，这种方式可以实现 比GB/T20438.2一2017中附录A规定的更高诊断覆盖率。但这些不同方法一定是独立的， 且不具有共因失效的可能

诊断功能及诊断覆盖率（

GB/T41295.22022

系统遵循了单一失效原则； PFDaVg/PFH满足了目标失效量的要求； SFF满足了架构约束的要求。 注：足够的诊断功能可以更加利于以上要求的实现，但并不是单单依靠诊断功能，例如，失效率高低和检验测试间 隔长短对于PFDavg/PFH是否满足要求也有重大影响。当这些要求无法满足时，可以考虑是否通过提高诊断 能力进行改善

PFDaVg/PFH满足了目标失效量的要求； SFF满足了架构约束的要求。 注：足够的诊断功能可以更加利于以上要求的实现，但并不是单单依靠诊断功能，例如，失效率高低和检验测试间 隔长短对于PFDavg/PFH是否满足要求也有重大影响。当这些要求无法满足时，可以考虑是否通过提高诊断 能力进行改善。 9.2.4.2诊断功能的设计满足检测到故障后系统的行为要求。 9.2.4.3需要但不限于在如下两个阶段执行诊断： 一在系统初始化时，诊断重点是所有的硬件，内部或外部数据通路等； 一正常运行时周期中执行诊断功能，诊断重点包括硬件、软件、软错误、数据通路等。 9.2.4.4宜基于系统的运行周期和所有诊断功能实现的时间，确定所有诊断的间隔时间，即诊断测试间 满（TD）。 9.2.4.5诊断测试间隔要足够小，以满足GB/T20438.2一2017中7.4.5.3和7.4.5.4。 9.2.4.6某些诊断功能为避免频繁的误动作，可能会采取多次判断后诊断决策的机制，需要考虑到这种 多次判断和重试可能会导致进人到某种死循环或无法实现所规定的诊断能力

在系统初始化时，诊断重点是所有的硬件，内部或外部数据通路等； 一正常运行时周期中执行诊断功能，诊断重点包括硬件、软件、软错误、数据通路等 9.2.4.4宜基于系统的运行周期和所有诊断功能实现的时间，确定所有诊断的间隔时间，即诊断测试间 隔（TD）。 9.2.4.5诊断测试间隔要足够小，以满足GB/T20438.2—2017中7.4.5.3和7.4.5.4。 .2.4.6某些诊断功能为避免频繁的误动作，可能会采取多次判断后诊断决策的机制，需要考虑到这种 多次判断和重试可能会导致进人到某种死循环或无法实现所规定的诊断能力

9.2.5.1架构约束的基本要求需要考虑满足GB/T20438.2一2017中7.4.4。 9.2.5.2宜优先选用GB/T20438.2—2017中7.4.4的路线11H），即通过硬件故障裕度（HFT）和安全 效分数（SFF）的确定来给出架构约束满足的SIL目标 9.2.5.3HFT的确定需要仔细分析采用的允余方式，某些允余的方式不能保证硬件故障裕度的提升。 注：例如采用一用一备的方式实现允余，正常时只有一个通道执行要求的处理功能，故障时切换到另一个通道，这 种情况下的HFT=0。 9.2.5.4合理的估算系统的SFF需要考虑： 不将无影响失效纳人SFF的计算之中； 诊断部分失效导致误动不能纳入SFF的计算之中 9.2.5.5安全失效分数的确定需要考虑到某些失效率很大的部件，如果该部件是安全失效，那么可能会 导致在没有执行足够的诊断情况下，SFF指标满足架构约束要求，这个是不符合安全准则的。

9.2.5.1架构约束的基本要求需要考虑满足GB/T20438.2一2017中7.4.4。 9.2.5.2宜优先选用GB/T20438.2一2017中7.4.4的路线1(1H），即通过硬件故障裕度（HFT）和安全 夫效分数（SFF）的确定来给出架构约束满足的SIL目标 9.2.5.3HFT的确定需要仔细分析采用的允余方式，某些允余的方式不能保证硬件故障裕度的提升。 注：例如采用一用一备的方式实现余，正常时只有一个通道执行要求的处理功能，故障时切换到另一个通道，这 种情况下的HFT=0。 9.2.5.4合理的估算系统的SFF需要考虑： 不将无影响失效纳人SFF的计算之中； 诊断部分失效导致误动不能纳人SFF的计算之中。 9.2.5.5安全失效分数的确定需要考虑到某些失效率很大的部件，如果该部件是安全失效，那么可能会 导致在没有执行足够的诊断情况下，SFF指标满足架构约束要求，这个是不符合安全准则的。

9.2.6硬件部分系统性失效的避免和控制

9.2.6.1为了避免硬件开发期间的系统性失效，需要考虑使用GB/T20438.2一2017中附录B的技术 和措施。 9.2.6.2在验证和确认阶段，需要有足够的证据证明这些技术和措施的确在研发过程得到了实施，并对 正据文档化。 9.2.6.3为控制系统性故障，系统设计需要考虑GB/T20438.2一2017中A.15A.18的要求，以满足 安全数据通信过程中对于系统性故障控制。 9.2.6.4在设计和开发活动中需要考虑可维护性和可测试性，以便在组合的最终安全相关系统中实现 这些特性。系统的设计需要考虑人员的能力和限制，并且能够分配给操作员和维护人员实施。所有接 1的设计宜考虑人员因素，并适应操作员可能具有的培训或意识等级，例如，大批量生产应用中操作员 可能仅接受过有限的培训。 注：设计目标是通过可能的设计或在完成前进行再次确认，来防止或消除由操作员或维护人员产生的可预见的关 键错误

GB/T41295.22022

9.2.7检测到故障时系统行为

.7.1需要考虑GB/T20438.2一2017中7.4.8的所有内容 .7.2在系统初始化时检测到危险故障，需要停止启动并给出相应的报警指示。 .7.3在系统运行期间检测到关键性危险故障，需要导致： 在制造商规定的故障响应时间内，通过内置措施（如硬件或嵌人式软件）将所有受故障影响的 输出切换到定义的安全状态；或 在制造商所规定的故障响应时间内，向应用措施（如应用程序）通知（报警）故障，从而应用措施 （如应用程序）可采取适当的动作来保持安全； 当以上任何一种情况发生后如果还没有进入安全状态，就意味着系统已经处于降级运行，系统 是否设计为当降级运行后在规定的时间内如果没有维修处理好需要自动的输出安全值，将过 程导入安全状态，降级后自动进入安全状态的功能不能被现场运行人员手动关闭；规定的时间 作为平均维修时间（MTTR）的影响因素之一纳入失效计算。 注1：关键性危险故障的定义在危险和风险分析时确定，通常来说是指那些无法执行安全功能且短时间内无 法自动恢复的危险故障 注2：何种动作合适取决于应用，功能安全系统研发团队可以将其设计为可配置的方式。 .7.4故障需要被检测并通知（报警）给应用程序，除非以下两种情况： 通过设计，该故障不可能在系统中发生； 由书面的技术评估证明故障可忽略

9.2.8安全数据通信

10.1.1软件设计和实现包括软件安全要求规范、软件架构设计和软件详细设计和实现。 10.1.2安全相关软件包括：系统的嵌人式固件、系统所应用的操作系统、系统所应用的安全数据库、在 线支持工具等。 10.1.3安全软件设计和实现的一般原则宜符合GB/T20438.3一2017。 施软件详细设计和实现

10.1.5按照GB/T20438.3一2017中7.3的要求编制软件确认计划

10.2.1软件安全要求规范

GB/T41295.22022

0.2.1.2需要考虑对软件安全要求规范进行持续追踪以确保所有要求得以正确实现。

10.2.2软件架构设计

0.2.2.1需要对软件架构设计的静态特性进行规范性描述（例如，架构框图），宜对组成系统架构的每 个模块和模块间接口进行描述， 0.2.2.2软件架构设计需要避免对每个模块内部的实现细节进行描述（如函数的参数），这些细节是后 续详细设计的内容。 10.2.2.3需要对软件的动态特性进行规范性描述，包括软件可能处于的运行状态描述，以及状态之间 的转移关系 0.2.2.4在软件架构设计中，宜适当的对数据规范、数据流、内存分配及存储空间余量方案等进行 描述。 0.2.2.5在对架构设计进行验证时，需要考虑至少采用一种规范性的分析方法（如系统级/模块级 FMEA），通过该方法以证明： 非安全相关的模块不会对安全相关模块造成负面影响； 足够的健壮性以保证在数据传输错误等情况发生时，系统不会进入危险状态，

10.2.3离线支持工具

0.2.3.1软件相关的离线支持工具包括：代码编辑器、编译器和连接器、模型化设计工具、 辑工具、软件测试工具、配置管理工具等

2.3.2需要按照GB/T20438.3一2017中7.4.4的要求考虑对离线支持工具的分类，包括： T1：不产生可直接或间接影响安全相关系统的可执行代码（包括数据）的输出； T2：支持设计或可执行代码的测试或验证，工具中的错误不能发现可执行软件的缺陷，但不会 在可执行软件中直接产生错误； 一T3：产生可直接或间接影响安全相关系统的可执行代码的输出。 注1：T1的示例包括：文本编辑器或没有自动代码生成能力的需求或设计支持工具；配置控制工具。 注2：T2的示例包括：测试装置生成器：测试覆盖度量工具；静态分析工具， 注3：T3的示例包括：源代码程序和生成的目标代码之间的关系不明显的优化编译器；将一个可执行运行时软件包 组合到可执行代码的编译器， 注4：此分类基于GB/T20438.4—2017中3.2.11 2.3.3对于按照GB/T20438.3一2017已经开展了符合性评估的离线支持工具，设计人员可以考虑 接按照工具手册的要求应用工具。 2.3.4对于没有按照GB/T20438.3一2017开展符合性评估的离线支持工具，设计人员需要对工具 适用性和正确性进行论证，并形成论证报告

0.2.3.2需要按照GB/T20438.3一2017中7.4.4的要求考虑对离线支持工具的分类，包括： T1：不产生可直接或间接影响安全相关系统的可执行代码（包括数据）的输出； T2：支持设计或可执行代码的测试或验证，工具中的错误不能发现可执行软件的缺陷，但不会 在可执行软件中直接产生错误； 一T3：产生可直接或间接影响安全相关系统的可执行代码的输出。 注1：T1的示例包括：文本编辑器或没有自动代码生成能力的需求或设计支持工其；配置控制工具。 注2：T2的示例包括：测试装置生成器；测试覆盖度量工具；静态分析工具 注3：T3的示例包括：源代码程序和生成的目标代码之间的关系不明显的优化编译器；将一个可执行运行时软件色 组合到可执行代码的编译器 注4：此分类基于GB/T20438.4—2017中3.2.11 0.2.3.3对于按照GB/T20438.3一2017已经开展了符合性评估的离线支持工具，设计人员可以考虑 直接按照工具手册的要求应用工具。 0.2.3.4对于没有按照GB/T20438.3一2017开展符合性评估的离线支持工具，设计人员需要对工具 的适用性和正确性进行论证，并形成论证报告

.2.4.1选用符合产品特性和适于软件设计人员的编程语言。 2.4.2针对特定的编程语言需要考虑编制适当的编码规则来规范和约束代码的实现，编码规则需 虑至少规定规范化的编码风格和可以使用和不能使用的编码形式

GB/T41295.22022

GB/T41295.22022

0.2.4.3编码规则的内容宜来自： 企业的已有类似项目的编码经验，公司规定等； 国际和国内通用的且被认可的编码规则或标准，如MirsaC/C十十等； 待实施项目的特殊情况，如编译环境或测试工具的特殊情况。

10.2.4.3编码规则的内容宜来自

10.2.5软件失效分析

10.2.5.1对SIL1和SIL2的软件宜开展软件失效分析，对于SIL3和SIL4的软件需要考虑开展软件失 效分析。 10.2.5.2软件失效分析的典型方法有：软件FMEA、软件危险与可操性分析（HAZOP）、软件形式化建 莫分析等。 10.2.5.3软件失效分析的结果保证所有安全相关模块的可预见故障都能得到相应的安全控制

.5.1对SIL1和SIL2的软件宜开展软件失效分析，对于SIL3和SIL4的软件需要考虑开展软件 析。 .5.2软件失效分析的典型方法有：软件FMEA、软件危险与可操性分析（HAZOP）、软件形式化 个析等。 .5.3软件失效分析的结果保证所有安全相关模块的可预见故障都能得到相应的安全控制

10.2.6.1对于某些软件模块，在执行本次功能安全系统设计之前就已经存在，并一直良好运 应用在之前类似系统上的通用软件模块），如果将这些软件模块复用于本次功能安全系统执行： 件安全功能，这些软件模块符合GB/T20438.3一2017中7.4.2.12。

10.2.7组件组合提高系统性能力

10.2.7.1可以考虑通过组合安全组件来提高系统性能力，见GB/T20438.2一2017中7.4.3。 10.2.7.2组合组件提高系统性能力的前提是组件之间具有足够的独立性，例如，两个通道之间的软件 是异构配置的。

10.2.8.1可以考虑通过分析或测试的方法来对软件开展验证， 10.2.8.2采用走查或审查等方式对软件代码或详细设计文件进行检查 10.2.8.3开展软件测试

10.2.9软件部分避免系统性失效

10.2.9.1为了避免软件开发期间的系统性失效，使用GB/T20438.3一2017中附录A、附录B和附录C 的相关技术和措施。 10.2.9.2在验证和确认阶段，需要有足够的证据证明这些技术和措施的确在研发过程得到了实施，对 证据文档化

GB/T41295.22022

系统还存在一个到多个层次的子系统集成，宜在生命周期早期阶段明确系统的集成方式。 1.1.2功能安全系统集成考虑符合GB/T20438.2一2017中7.5（子系统集成）和GB/T20438.3 2017中7.5（软硬件集成）。 11.1.3在硬件和软件架构设计阶段编制集成测试计划

.2.1在集成阶段执行故障插入测试。 .2.2故障插人测试用例的设计和执行参考GB/T41295.3。 1.2.3故障插入测试的执行得到第三方独立机构见证，并产生基于见证结论的故障插入测试报告

12系统运行和维护规程

.1.1功能安全系统研发团队宜基于产品的基本功能和应用特性编制用户手册，包括安装、维护要 功能安全系统研发团队还需要基于产品的功能安全属性编制安全手册，包括安全配置方式、危险 参数等。 .1.2用户手册和安全手册从形式上可以是一个或多个文档。 .1.3安全手册的内容至少需要考虑GB/T20438.2—2017和GB/T20438.3—2017中附录工 求。 .1.4 用户手册和安全手册需要考虑随功能安全系统在发货时移交给集成单位或用户单位

等；功能安全系统研发团队还需要基于产品的功能安全属性编制安全手册，包括安全 效参数等。

等；功能安全系统研发团队还需要基于产品的功能安全属性编制安全手册，包括安全配置方式、危险失 改参数等。 2.1.2用户手册和安全手册从形式上可以是一个或多个文档。 12.1.3安全手册的内容至少需要考虑GB/T20438.2—2017和GB/T20438.3—2017中附录D的 要求。 12.1.4 用户手册和安全手册需要考虑随功能安全系统在发货时移交给集成单位或用户单位

12.1.2用户手册和安全手册从形式上可以是一个或多个文档。

主手册中详细说明，包括安全模块的应用 时间约束等：

安全功能可使用的那些功能和接口的规范，如应用限制、通信限制； 可导致危险的系统失效，并能被诊断测试检测到的随机硬件失效率的估计； 可导致危险的系统失效，并不能被诊断测试检测到的随机硬件失效率的估计； 对保持失效率有效性的环境限制； 预期系统所处的机械和气候环境（如振动、冲击、温度、湿度）； 制造商声明的系统最大使用寿命，该寿命应等于或小于20年，除非系统制造商能提供证据证 明更长的寿命，这些证据基于计算，表明其可靠性数据对于更长寿命是有效的 注：系统中的有些单个元件已知寿命小于20年。典型示例包括：电池、电解电容、LED等。如有必要，对这些 元件的定期更换作为系统制造商规定的常规维护规程的一部分。定义最大20年使用寿命是为了覆盖大 部分未知寿命的系统元件， 定期检验测试方法、时间间隔和/或维护要求； 系统内部的诊断覆盖率； 系统内部的诊断测试间隔 如适用，平均恢复时间（MTTR）和平均维修时间（MRT）； 安全失效分数（SFF）； 硬件故障裕度； 为避免系统性失效建议的应用限制； 所用元件的降额；

GB/T41295.22022

适宜使用系统的安全相关系统的可声明SIL； 系统的硬件版本； 系统已得到确认的文档证据

适宜使用系统的安全相关系统的可声明SIL 系统的硬件版本； 系统已得到确认的文档证据

3.1.1系统的确认需要符合 2017中7.7和GB/T20438.3—2107中7.7。

13.2.1保证安全要求规范中的所有内容都得到了确认，宜建立确认项与安全要求规范条款的对应关

13.2.1保证安全要求规范中的所有内容都得到了确认，宜建立确认项与安全要求规范条款的对应关 系矩阵，以清楚的显示所有的确认关系， 13.2.2确认的部分项目可以考虑在功能安全系统研发团队内部进行（如功能测试），也可以考虑通过 外部第三方实验室开展（如型式试验）。与确认相关的功能安全测试按照GB/T41295.3进行

14生命周期各个阶段的验证

在执行以上功能安全系统生命周期过程中抽样标准，在每个阶段的工作完成后，需要考虑开展对该阶段的验 正工作。 每个系统生命周期阶段交付内容的验证工作需要计划、执行和文档化。这些验证需要考虑到基于 主命周期各阶段输人的规定。验证所使用的技术/工具包括，例如： 阶段性文档的复审； 设计复审； 功能测试； 环境测试。 注，验证不要与校准和确认相混潘

在执行以上功能安全系统生台 工作。 每个系统生命周期阶段交付内 命周期各阶段输入的规定。验证 阶段性文档的复审； 设计复审； 功能测试； 环境测试。 注：验证不要与校准和确认相混淆

15.1对功能安全系统制造的主要目的是保证制造过程的功能安全目标能够得到保持。

GB/T41295.22022

下装到系统中，包括下装前的人工核对，下装后的一致性检查等。 注：可以采用的措施包括校验和比对，回读比较等。 15.5对于SIL3和SIL4应用的功能安全系统生产过程，需要考虑开展适当的失效分析，分析生产过程 中可能出现的合理可预见的失效情况，并采取适当的措施来避免或控制这些失效典型的方法如过程失 效模式与影响分析（PFMEA）」，在正式生产前需要考虑对相应的控制措施进行验证， 15.6功能安全系统制造团队需要制定变更管理计划，以保证当制造过程发生了变化后不会造成新的 制造风险。 15.7变更管理计划需要考虑到功能安全系统本身出现变更的情况，例如，如果制造过程发现了功能安 全系统本身的设计问题，需要协同研发团队执行变更过程。 5.8面向生产制造相关人员对所有以上要求开展培训。 5.9所有测试设备都应在适当的管理体系受控下，包括定期的核查、校准和维护等。 15.10制定程序来规定对于功能安全系统内关键元器件的有效检验，以保证系统的失效率不会因为元 器件的偶发问题出现异常而大幅度升高，关键元器件由研发团队基于失效分析结论确定。 15.11制定详细的程序来规定制造后端的检验和测试，包括例行检验、确认检验和工厂验收测试。除 了常规的功能和性能测试之外，还需要对系统的典型故障反应开展测试， 15.12检验和测试需要保证不会对系统的安全性造成负面影响，如果不确定这种影响应对测试方法开 展适当的论证，并将论证结论详细的告知给操作人员

16功能安全系统评估评测

16.1对于特定的功能安全系统，为证明第5章～第15章内容的有效实施，需要考虑开展独立的功能 安全评估评测 16.2功能安全评估评测机构来自独立于功能安全系统研发制造单位的第三方组织，评估评测机构是 经相关机构授权的具有功能安全标准认可能力的实验室、检验机构或认证机构 16.3功能安全评估评测机构需要建有满足功能安全评估评测技术的实验场地，配置有适当的测试设 备、软件和工具。 16.4功能安全评估评测的人员需具备足够的资质，包括对于功能安全技术的理解和对于待评估产品 的理解。 16.5具备必要的测试设备、软件和工具，至少包括： 专用的功能安全失效分析工具； 专用的故障模拟或仿真工具以实现适当的故障插人测试； 一安全功能和性能测试的必要环境条件。 16.6功能安全系统的评估评测至少包含以下适用内容： 对建立的安全生命周期和功能安全管理开展评估： 对形成的所有安全相关证据文档开展评估； 一对系统和硬件设计的安全性进行评测； 一对软件设计的安全性进行评测； 基于安全机制的设计和失效分析结论，评估评测人员设计故障插入测试用例，执行或现场目击 故障插人测试，完成故障插人测试报告； 对功能安全系统研发团队执行的系统、硬件和软件测试的合理性和完备性开展评测（参见 GB/T41295.3），检查所有的测试计划、测试记录和测试报告； 一必要的测试需在功能安全评估评测机构授权的实验室内开展，至少包括：关键的故障捕人测 试、环境条件下的关键功能和性能测试、安全通信检错能力测试、关键软件模块的单元测试：

对形成的用户手册和安全手册开展评估； 对功能安全系统的制造能力开展评估； 形成基于以上评估评测结论的过程记录和标准符合性检查表； 编制评估评测报告。 16.7在完成评估评测工作之后，形成面向特定功能安全系统的评估评测报告，报告中至少包括： 评估评测的对象，包括详细的软硬件模块、系统结构、版本和文档： 评估评测的实施周期和人员； 评估评测依据的标准规范，采用的方法和策略； 特定生命周期阶段的符合性结论； 评估评测的约束条件和有效期。 16.8功能安全系统在其他第三方机构开展的测试（如型式试验）需要首先经过功能安全评估评测 的认可。

暖通空调管理GB/T41295.22022