首页  思维导图  详情

ISO26262-Part5

2023-10-25 09:19:57   0  举报





AI智能生成

ISO26262-Part5

功能安全

作者其他创作

大纲/内容

ISO26262-Part5
Hardware development

6 硬件安全要求的定义工作成果
6 Specification of hardware safety requirements

6. 5. 1 硬件安全需求规范(包括测试和评估准则),由 6. 4. 1~6. 4. 8 的要求得出。
6.5.1HW Safety Requirement specification

6. 4. 1 相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出(源自 GB / T34590. 4 —
2022 中 6. 5. 2 )。

GB / T34590. 4 —2022 中 6. 5. 2 技术安全概念,由 6. 4. 3~6. 4. 6 的要求得出。

6. 4. 3 系统架构设计规范和技术安全概念

6. 4. 3. 1 技术安全概念和该子阶段的系统架构设计应基于相关项定义,功能安全概念和先前的系统架
构设计。

6. 4. 3. 2 应检查 GB / T34590. 3 — 2022 中 7. 3. 1 的系统架构设计和本子阶段中的系统架构设计的一致性。如果发现差异,则可能有必要对 GB / T34590.3 — 2022 描述的活动进行迭代。

6. 4. 3. 3 系统架构设计应实现技术安全要求。

6. 4. 3. 4 关于技术安全要求的实现,系统架构设计应考虑:

a ) 验证系统架构设计的能力;

b ) 与实现功能安全相关的预期软硬件要素的技术能力;

c ) 在系统集成过程中执行测试的能力。

6. 4. 3. 5 应定义安全相关要素的内部和外部接口,其他要素不应对安全相关要素产生不利的安全相关
影响。

6. 4. 3. 6 如果在系统架构设计期间对安全要求进行 ASIL 等级分解,应按照 GB / T34590. 9 — 2022 第 5
章进行。

6. 4. 4 安全分析及避免系统性失效

注 1 :安全相关特性包括独立性和免于干扰的要求。
注 2 :这些分析的目的是辅助设计。因此在该阶段,定性分析是足够的。如果有必要,采用定量分析。
注 3 :在足以识别随机硬件失效和系统性失效的原因和影响的细节层面上进行分析。
注 4 :演绎和归纳的方法结合使用的目的是提供互补的分析方法,见 GB / T34590.9 — 2022 中的 8. 2 。

6. 4. 4. 2 为符合安全目标或要求,应消除已识别出的引起失效的内部原因,或在必要时减轻它们的影响。

6. 4. 4. 3 为符合安全目标或要求,应消除已识别出的引起失效的外部原因,或在必要时减轻它们的影响。

6. 4. 4. 4 为了减少系统性失效的可能性,宜在适用处应用值得信赖的系统设计原则。

a ) 值得信赖的技术安全概念的复用;

b ) 值得信赖的要素设计的复用,包括硬件和软件组件;

c ) 值得信赖的探测和控制失效的机制的复用;

d ) 值得信赖的或标准化接口的复用

6. 4. 4. 5 应对值得信赖的设计原则的适用性进行分析并形成文档,以确保其和最终产品应用的一致性和适用性。

6. 4. 4. 6 为了避免系统性故障,系统架构设计应具有以下特征
注:可以通过使用诸如分层的设计,精确的接口定义,避免组件和接口不必要的复杂性,可维护性和可验证性之类
的设计原则实现上述特征。

a ) 模块化;

b ) 适当的颗粒度水平;

c ) 简单。

6. 4. 4. 7 在安全分析或系统架构设计过程中新识别的尚未被安全目标涵盖的危害,应更新到按照GB / T34590. 3 — 2022 定义的危害分析和风险评估( HARA )中。
注:安全目标尚未涵盖的危害可能是非功能性危害。非功能性危害不在 GB / T34590 的范围内,但可在危害分析和风险评估中增加注释;例如,通过增加“此危害中未指定 ASIL 等级,因为它不在 GB / T34590 的范围内”的注释进行说明。

6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 1 应按照 6. 4. 3 中的系统架构设计,定义探测、控制或减轻随机硬件失效的措施。
示例 1 :这些措施可能是硬件的诊断特性,通过软件对其的使用来探测随机硬件失效。
示例 2 :随机硬件失效发生时,不需要探测即可进入安全状态的硬件设计(即:失效 - 安全的硬件设计)。
注: 6.4. 4. 1 中归纳和演绎分析的量化估计有助于确定是否需要采取进一步的安全措施,并进行硬件分析,做出最终
决定,见 GB / T34590.5 — 2022 。

6. 4. 5. 2 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应选择可替代流程中的一个,用于评估随机硬件失效导致的对安全目标的违背 (见 GB / T34590.5 — 2022 第 9 章),并应定义目标值以用于相关项层面的最终评估。

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

6. 4. 5. 4 本要求适用于 ASIL ( B )、 C 和 D 等级。对于分布式开发(见 GB / T34590. 8 — 2022 第 5 章),推导出的目标值应通报给每个相关团队。
注: GB / T34590.5 — 2022 第 8 章和第 9 章中描述的架构约束,不一定适用于商业现成产品的元器件和组件。这是因为供应商通常不能预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下,供应商会提供基本的数据,例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等,以便允许在整体硬件架构层面上预估架构约束。

6. 4. 6 分配到硬件和软件

6. 4. 6. 1 技术安全要求应分配给以系统、硬件或软件作为实施技术的系统架构设计要素。
注:如果将技术安全要求分配给作为实施技术的系统中,则再次按照 GB / T34590.4 — 2022 进一步开发这些要求,
直到能将他们分配给硬件和软件为止。

6. 4. 6. 2 分配和分区决策应符合系统架构设计。
注:为了实现独立性和避免失效传播,系统架构设计可以采用功能分区和组件分区。

6. 4. 6. 3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

6. 4. 6. 4 如果系统架构设计要素由指定为不同 ASIL 等级的子要素组成,或由安全相关和非安全相关的子要素组成,那么每个子要素都应按照最高 ASIL 等级进行处理,除非满足共存标准 (按照GB / T34590. 9 — 2022 第 6 章)。

6. 4. 6. 5 如果技术安全要求分配到具备可编程功能的定制化硬件要素[如专用集成芯片( ASIC )、可编程门阵列(FPGA )或是其他形式的数字化硬件],宜结合 GB / T34590. 5 — 2022 和 GB / T34590. 6 — 2022 的要求来定义和实施适当的开发流程。
注 1 :如果满足 GB / T34590.8 — 2022 第 13 章的应用准则,则可以按照该章的评估方法提供证据证明上述硬件要素中的一些要素满足所分配的安全要求。
注 2 : GB / T34590.11 — 2022 提供了相应指导。

6. 4. 2 硬件安全需求规范应包括与功能安全有关的每一条硬件要求

a ) 为控制要素硬件内部失效的硬件安全要求和安全机制的相关特性。这包括用于覆盖瞬态故障
(例如,由于所使用的技术而产生的瞬态故障)
示例 1 :特性可能包括看门狗的定时和探测能力。

b ) 为控制或者容忍要素外部失效的硬件安全要求和安全机制的相关特性;
示例 2 :当外部失效发生时,如 ECU 的输入开路时,要求 ECU 应具备的功能表现。

c ) 为符合其他要素的安全要求的硬件安全要求和安全机制的相关特性;
示例 3 :对传感器或执行器的诊断。

d ) 为探测内外部失效和发送失效信息的硬件安全要求和安全机制的相关特性;
注 1 : d )中描述的硬件安全要求包括防止故障潜伏的安全机制。
示例 4 :安全机制中定义的硬件元器件的故障响应时间,要符合故障容错时间间隔。

e ) 不定义安全机制的硬件安全要求。
示例 5 :举例如下:
———为满足 6.4. 3 和 6. 4. 4 所描述的随机硬件失效目标值的硬件要素要求;
———为避免特定行为的要求(例如,“一个特定的传感器不应该有一个不稳定的输出”);
———分配给执行预期功能的硬件要素的要求;
———定义线束或接插件的设计措施的要求。
注 2 :安全机制能用硬件、软件或软硬件结合的方式来实现。

6. 4. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。当为相关项硬件要素推导目标值时,应考虑按照 GB / T34590.4 — 2022 中 6. 4. 5 的要求,为本文件第 8 章定义的度量设定目标值。

GB / T34590.4 — 2022 中6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

6. 4. 4 本要求适用于等级为 ASIL ( B ), C 和 D 的安全目标。当为相关项硬件要素推导目标值时,应考虑按照 GB / T34590.4 — 2022 中 6. 4. 5 的要求,为本文件第 9 章定义的过程设定目标值。
注:除非同意使用 9.4. 3 中规定的 EEC ,否则在 GB / T34590. 8 — 2022 第 5 章定义的分布式开发情况下,此活动可能包括 PMHF 目标值的分配。

GB / T34590.4 — 2022 中6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

6. 4. 5 硬件安全要求应按照 GB / T34590. 8 — 2022 第 6 章的要求进行定义。

6. 4. 6 应定义相关项的硬件要素的设计验证准则,包括环境条件(温度、振动、 EMI 等)、特定的运行环境(供电电压、任务剖面等)以及组件的特定要求:

a ) 通过硬件要素评估进行的验证,其准则应满足 GB / T34590. 8 — 2022 第 13 章的要求;

GB / T34590. 8 — 2022 第 13 章

13. 5. 1 硬件要素评估计划,由 13. 4. 3. 2 的要求得出。

13. 4. 3. 2 评估计划应开发评估计划,并应描述:

a ) 硬件要素的唯一识别及版本;

b ) 硬件要素预期使用环境的定义;

c ) 评估策略和依据;
注:策略包括分析、必要的测试和逐步的描述。

d ) 该策略所必需的工具和设备;

e ) 实施该评估的责任方;

f ) 用于评估硬件要素通过和不通过的准则。

13. 5. 2 如果适用,硬件要素测试计划,由 13. 4. 3. 5. 1 的要求得出。

13. 4. 3. 5. 1 应制定测试计划,且测试计划应包含下列信息:

a ) 硬件要素的功能描述;

b ) 所分配的安全要求;

c ) 需要进行的测试规范和顺序;

d ) 测试与安全要求之间的追溯性;

e ) 组装和连接的要求;

f ) 需要模拟的运行条件和环境条件;

g ) 被测要素的数量;

h ) 测试通过/不通过的准则;

i ) 需要测量的环境参数;

j ) 对测试设备的要求,包括精度。

13. 5. 3 如果适用,硬件要素评估报告,由 13. 4. 1. 1 、 13. 4. 3. 6 和 13. 4. 4. 3 的要求得出。

13. 4. 1. 1 被评估硬件要素的分类硬件要素应被分为以下类别之一:

a ) Ⅰ 类要素,如果:
———该要素最多有几种状态,且这几种状态可以从安全的视角被充分地表征、测试和分析;
———可以在不了解该要素的实现细节和生产过程的情况下,识别并评估该要素的安全相关的失效模式;
———该要素没有与安全概念相关的控制或探测其内部失效的内部安全机制。
注 1 :这并不包含监控要素外部特性的安全机制。
示例 1 :电阻、电容、晶体管、二极管、晶振、谐振器。

b ) Ⅱ 类要素,如果:
———具有例如较少运行模式、较小取值范围、较少参数的要素,并且可以在不了解实现细节的情况下从安全的角度对其进行分析;
———现有的文档可以提供有效的假设,以支持通过测试和分析评估系统性故障,而无需了解该要素的实现细节和生产过程;
示例 2 :数据表、用户手册、应用说明。
———该要素没有与安全概念相关的控制或探测其内部失效的内部安全机制。
注 2 :这并不包含监控要素外部特性的安全机制。
示例 3 :燃油压力传感器、温度传感器、没有与安全概念相关的内部安全机制的独立模数转换器( ADC )。

c ) Ⅲ 类要素,如果:
———具有例如较多运行模式、较大取值范围、较多参数的要素,并且在不了解实现细节的情况下,不能进行分析;
———系统性故障的来源只能通过实现细节、开发过程和/或生产过程的方式来理解和分析;或
———该要素具有与安全概念相关的控制或探测

13. 4. 3. 6 评估报告

13. 4. 3. 6. 1 评估报告应说明,基于所执行的分析和测试,针对定义并分配给该硬件要素的安全要求(包括其工作范围和条件),硬件要素是否通过了评估。
注:评估报告可由包括调查报告和解释记录在内的一系列文档组成。

13. 4. 3. 6. 2 应按照第 9 章对评估报告进行验证。

13. 4. 4. 3 应提供额外措施,证明由于系统性故障而违背安全目标或违背安全要求的风险足够低。
注 1 :根据提供的论证组合,硬件评估的结果表明在给定应用的情况下使用 Ⅲ 类要素是安全的。但是该论证并非对所有应用都有效。
注 2 :措施可以包括但不限于:
a ) 安全相关功能的可验证性;
b ) 现场经验/“值得信赖的组件”;
注 3 :现场经验可以作为硬件评价的一部分支持性论证。对于完整的在用证明论证,则遵循GB / T34590. 8 — 2022 的第 14 章,而非本章。
c ) 由具备安全相关失效模式检测能力的、独立的多样化要素进行监控;
注 4 :独立性可通过符合 GB / T34590.9 — 2022 中第 7 章的相关失效分析来显示。
d ) 符合不同安全标准但具有同等完整性等级的开发。

b ) 通过测试进行的验证,其准则应满足本文件第 10 章的要求。

6. 4. 7 硬件安全要求应符合 GB / T34590. 4 — 2022 中 6. 4. 2 定义的安全机制的故障容错时间间隔,或者最大故障处理时间间隔。
注:硬件设计中能定义一种能够控制故障,但不能满足容错时间间隔或最大故障处理时间间隔的机制。在这种情况下,进行本文件的第 8 章和第 9 章的定义的度量评估和 ASIL 等级分解时,不能考虑该机制。

GB / T34590. 4 — 2022 中 6. 4. 2 安全机制

6. 4. 2. 1 技术安全要求应定义安全机制,用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求(见 GB / T34590.
3 — 2022 第 7 章)的失效,包括:

a ) 与系统自身故障的探测、指示和控制相关的安全机制;
注 1 :包括用于探测随机硬件故障及探测系统性故障(如果适用)的系统自身监控。
注 2 :包括对通信通道失效(例如:数据接口、通信总线、无线射频链接)的探测和控制的安全机制。
注 3 :可以在系统架构适当的层级定义安全机制。

b ) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制;
示例:外部设备包括其他的电控单元、电源或者通信设备。

c ) 使系统实现或者维持在相关项的安全状态的安全机制;
注 4 :包括来自安全机制的多个控制请求的仲裁。

d ) 定义和执行报警和降级策略的安全机制;

e ) 防止故障处于潜伏故障的安全机制。
注 5 :如同 a ) ~d ),这些安全机制通常与上电过程(运行前检查)、运行中、下电过程(运行后检查)及维护过程
中发生的自检相关。

6. 4. 2. 2 对于每个使相关项实现安全状态或维持安全状态的安全机制,应定义下列内容:

a ) 状态间的转换;
注 1 :包括控制执行器的要求。

b ) 与从适当的架构层级分配得到的时间要求相关的故障处理时间间隔;
注 2 :该子要求的目的是在针对每个安全目标定义的故障处理时间间隔的范围内,实现时间一致。

c ) 不能在 FTTI 内进入相关项安全状态时的紧急运行容错时间间隔(见 GB / T34590. 1 — 2022 中的3. 45 )。
注 3 :整车测试和试验能够用于确定紧急运行容错时间间隔。
示例 1 :安全状态之前的降级运行持续时间。
示例 2 :一个依赖于电源的线控制动应用的安全机制,可以包括定义备用电源或储能设备(容量、启动和运行时间等)。

6. 4. 2. 3 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。如果适用,应定义安全机制,以防止故障处于潜伏故障。
注 1 :仅随机硬件故障的多点故障有可能成为潜伏故障。
示例:自检可作为检测多点故障的安全机制。用于验证组件在不同运行模式(例如上电、下电、运行或额外的自检模式)下的状态。阀、继电器或灯在常规上电时进行的功能检测就是自检的例子。
注 2 :识别是否需要防止故障处于潜伏状态的安全机制的评估标准来源于良好的工程实践。 GB / T34590.5 — 2022第 8 章给出的潜伏故障度量提供了评估标准。

6. 4. 2. 4 此要求适用于 ASIL ( A )、( B )、 C 和 D 等级。为了避免多点失效,应为每个探测多点故障的安全机制定义诊断测试策略,包括:

a ) 硬件组件的可靠性要求,并考虑其在架构中的角色及其对多点失效的贡献;

b ) 定义的量化目标值,表征由于随机硬件失效而违背各安全目标的最大可能性(见 GB / T34590. 5 —2022 第 9 章);

c ) 已分配的 ASIL 等级,从相关安全目标、功能安全要求或更高层面的技术安全要求中导出;

d ) 多点故障探测时间间隔。
注 1 :诊断测试策略可以是时间驱动(例如使用诊断测试时间间隔)或者事件驱动(例如启动测试)。
注 2 :二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。
注 3 :下列措施的使用取决于时间约束:
———系统或要素在运行过程中的周期性测试;
———要素在上下电时的自检;
———系统或要素在维护时的测试。

6. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应至少符合:

a ) ASILB 等级(对于分配为 ASILD 等级的技术安全要求)

b ) ASILA 等级(对于分配为 ASILB 等级和 ASILC 等级的技术安全要求);

c ) QM 等级(对于分配为 ASILA 等级的技术安全要求)。
注:如果安全要求运用了 ASIL 等级分解,那么本章的要求亦适用于分解后的要求。
示例:某内存存储采用奇偶校验作为安全机制,其安全要求被评为 ASILB 等级。针对用于测试该奇偶校验机制在探测和指示内存故障的能力的自检测试,其要求可被评为 ASILA 等级。

6. 4. 8 硬件安全要求应符合按照 GB / T34590. 4 — 2022 中 6. 4. 2 定义的多点故障探测时间间隔。
注 1 :对于 ASIL 等级为 C 和 D 的安全目标来说,如果对应的安全概念没有描述明确的量值,多点故障探测时间间隔能定义为等于或小于该相关项从上电到下电的周期。
注 2 :合适的多点故障探测时间间隔也能通过对随机硬件失效的发生概率的定量分析来确定(见第 9 章)。

GB / T34590. 4 — 2022 中 6. 4. 2 安全机制

6. 4. 2. 1 技术安全要求应定义安全机制,用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求(见 GB / T34590.
3 — 2022 第 7 章)的失效,包括:

b ) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制;
示例:外部设备包括其他的电控单元、电源或者通信设备。

c ) 使系统实现或者维持在相关项的安全状态的安全机制;
注 4 :包括来自安全机制的多个控制请求的仲裁。

d ) 定义和执行报警和降级策略的安全机制;

6. 4. 2. 2 对于每个使相关项实现安全状态或维持安全状态的安全机制,应定义下列内容:

a ) 状态间的转换;
注 1 :包括控制执行器的要求。

6. 4. 2. 4 此要求适用于 ASIL ( A )、( B )、 C 和 D 等级。为了避免多点失效,应为每个探测多点故障的安全机制定义诊断测试策略,包括:

a ) 硬件组件的可靠性要求,并考虑其在架构中的角色及其对多点失效的贡献;

b ) 定义的量化目标值,表征由于随机硬件失效而违背各安全目标的最大可能性(见 GB / T34590. 5 —2022 第 9 章);

c ) 已分配的 ASIL 等级,从相关安全目标、功能安全要求或更高层面的技术安全要求中导出;

6. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应至少符合:

a ) ASILB 等级(对于分配为 ASILD 等级的技术安全要求)

b ) ASILA 等级(对于分配为 ASILB 等级和 ASILC 等级的技术安全要求);

6. 5. 2 软硬件接口规范(细化的),由 6. 4. 10 的要求得出。
注:此工作成果可以参考 GB / T34590.6 — 2022 中 6. 5. 2 给出的相同的工作成果。

6. 4. 10 在 GB / T34590. 4 — 2022 中 6. 4. 7 最初定义的软硬件接口应被充分细化,以允许硬件被软件正确地控制和使用,并且应描述出硬件和软件之间的每一项安全相关的关联性。

6. 5. 3 硬件安全要求验证报告,由 6. 4. 9 和 6. 4. 11 的要求得出。

6. 4. 9 硬件安全要求应按照 GB / T34590. 8 — 2022 第 9 章的要求进行验证,以提供证据证明其:

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

i ) 回归策略。
注 2 :回归策略定义了在相关项或要素变更后如何重复进行验证。验证可以被全部或部分重复,并可包含其他能影响验证结果的相关项或要素。

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

c ) 前提条件和配置;
注 1 :如果对工作成果的可能配置(例如,系统变型)进行完整验证是不可行的,可选择一个合理的子集(例如,系统的最小或最大功能性配置)。

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

f ) 期望的表现,包括输出数据、输出值的可接受范围、时间表现和公差表现;
注 3 :当定义期望的表现时,对初始输出数据的定义可能是必要的,以探测变化。
注 4 :为避免重复定义和存储不同测试用例用到的前提条件、配置及环境条件,有必要使用明确的参考。

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

e ) 验证通过或不通过的明确的陈述,如果验证不通过,陈述应包含不通过的理由和对所验证工作成果进行修改的建议;
注:按照验证的完成和结束准则[见 9.4. 1. 1d )]和预期的验证结果,对验证进行评估。

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

a ) 与技术安全概念、系统设计规范以及硬件规范的一致性;

b ) 关于技术安全要求分配给硬件要素的完整性

c ) 与相关软件安全要求的一致性;

d ) 正确性与准确性

7 硬件设计工作成果
7 Hardware design

7. 5. 1 硬件设计规范,由 7. 4. 1 和 7. 4. 2 的要求得出。

7. 4. 1 硬件架构设计

7. 4. 1. 1 硬件架构应实现第 6 章定义的硬件安全要求。

7. 4. 1. 2 硬件安全要求应分配到对应的硬件要素,因此,每个硬件要素都应按照分配给它的所有要求中最高的 ASIL 等级来开发。
注:硬件要素的各个特征将继承该要素所实现的硬件安全要求中最高的 ASIL 等级

7. 4. 1. 3 如果在硬件架构设计中对硬件安全要求应用了 ASIL 等级分解, ASIL 等级分解应按照GB / T34590. 9 — 2022 第 5 章的要求进行。

7. 4. 1. 4 如果一个硬件要素是由 ASIL 等级低于要素 ASIL 等级或没有指定 ASIL 等级的子要素组成,除非满足按照 GB / T34590.9 — 2022 第 6 章的共存准则,否则应按照最高的 ASIL 等级处理每个子要素。

7. 4. 1. 5 对硬件安全要求和硬件架构设计要素之间的可追溯性,应保持到硬件组件的最底层。
注:硬件安全要求的可追溯性不要求深入到硬件详细设计。对于不能划分为子元器件的硬件元器件,不分配硬件安全要求。例如,试图建立每个电容和电阻等硬件的可追溯性既没有意义,也没有益处。

7. 4. 1. 6 为避免系统性故障,应通过使用表 1 中列出的原则,使硬件架构设计具有下述特性:

a ) 模块化;
注 1 :模块化使得硬件要素的设计无需修改就可以重复使用(如温度探测电路模块、微控制器中的 ECC模块)。

b ) 适当的粒度水平;
注 2 :其目的是架构在必要的详细程度上体现必要的信息,来显示安全机制的有效性

c ) 简单性。

7. 4. 1. 7 在硬件架构设计时,应考虑安全相关硬件组件失效的非功能性原因,如果适用,可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素或自硬件架构的其他硬件组件或其所在环境的串扰。

7. 4. 2 硬件详细设计

7. 4. 2. 1 为了避免常见的设计缺陷,按照 GB / T34590. 2 — 2022 中的 5. 4. 2. 6 ,应运用相关的经验总结

GB / T34590. 2 — 2022 中的 5. 4. 2. 6 基于以下几点,组织应建立、执行并维护持续改进的流程:
———从其他相关项安全生命周期的执行过程中学习经验,包括现场经验;
———将获得的改进应用于后续相关项

7. 4. 2. 2 在硬件详细设计时,应考虑安全相关硬件元器件失效的非功能性原因,如果适用,可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素：来自硬件组件的其他硬件元器件或其所在环境的串扰。

7. 4. 2. 3 按照硬件详细设计,应考虑硬件元器件或硬件组件的任务剖面和运行条件,以确保硬件元器件或硬件组件在其规格范围内运行,以避免其由于预期使用而发生失效。

7. 4. 2. 4 宜考虑鲁棒性设计原则。
注:鲁棒性设计原则可以通过硬件设计指南的应用来体现。
示例:关于组件应对环境和运行应力因素鲁棒性的保守规范。

7. 5. 2 硬件安全分析报告,由 7. 4. 3 的要求得出。

7. 4. 3 安全分析

7. 4. 3. 1 硬件设计的安全分析,应按照表 2 和 GB / T34590. 9 — 2022 中的第 8 章进行,以识别失效的原因和故障的影响。
注 1 :安全分析的最初目的是支持硬件设计的定义,其后,安全分析能用于硬件设计验证(见 7.4. 4 )。
注 2 :就安全分析支持硬件设计定义的目的来说,定性分析可能是适当且充分的。

7. 4. 3. 2 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。对于每个安全相关的硬件组件或元器
件,针对所考虑的安全目标,安全分析应识别以下内容：

a ) 安全故障;

b ) 单点故障或残余故障;

c ) 多点故障(无论是可感知的、可探测的或潜伏的)。

注 1 :识别多点故障的目的,并不要求对每一种可能的两个硬件故障的组合进行系统的分析,但至少要考虑从技术安全概念得出的组合(例如,两个故障的组合:一个故障影响了安全相关的要素,另一个故障影响了相应的为达到或维持安全状态所需的安全机制)。
注 2 :在大多数情况下,分析可能限制到双点故障。但有时阶次高于 2 的多点故障可能显示与技术安全概念有关(例如,当执行冗余安全机制时)。

7. 4. 3. 3 本要求适用于等级为 ASIL ( A )、( B )、 C 和 D 的安全目标。应具备实施的安全机制对防止导致单点失效的故障或减少残余故障的有效性的证据。
为了这个目的:

a ) 应具备证据以证明安全机制具有实现和保持安全状态的能力(特别是在容错时间间隔和最大故障处理时间间隔内适当的失效减轻能力);

b ) 应评估由安全机制实现的残余故障的诊断覆盖率。

注 1 :一个可能在任何时间(例如,不仅在上电时)发生的故障,如果故障探测时间间隔加上相应安全机制的故障响应时间,大于相应的容错时间间隔或指定的最大故障处理时间间隔,则不能认为此故障被有效覆盖。
注 2 :如果能证明某一特定故障模式可能仅发生在上电时,并且在车辆行驶期间发生的概率是可以忽略的,那么对这些故障仅在上电后执行启动测试是可以接受的。
注 3 :能用例如 FMEA 或 FTA 分析来构建理由。
注 4 :根据对硬件要素失效模式和它们对更高层面的影响的认知,这种评估可能是硬件要素的整体诊断覆盖率,或更详细的失效模式的覆盖率评估。
注 5 :附录 D 可以作为起始点,为已制定的安全机制确定诊断覆盖率。所声明的诊断覆盖率需要合适的理由支持
(见 GB / T34590. 10 — 2022 残余失效率评估条款和 GB/ T34590.11 — 2022 附录 A 中的示例)。
注 6 :本要求适用于硬件、软件或两者结合实现的安全机制。

7. 4. 3. 4 本要求适用于等级为 ASIL ( A )、( B )、 C 和 D 的安全目标。应具备实施的安全机制对防止潜伏故障的有效性的证据。
为了这个目的:

a ) 应具备证据以证明安全机制在可接受的多点故障探测时间间隔内完成潜伏故障的失效探测和实现或保持安全状态及警示驾驶员的能力,以确定哪些故障保持潜伏,哪些故障可被探测到;

b ) 应评估由安全机制实现的潜伏故障的诊断覆盖率。

注 1 :如果一个相应安全机制的故障处理时间间隔大于相应的潜伏故障的多点故障探测时间间隔,则不能认为此故障被有效覆盖。
注 2 :能用例如 FMEA 或 FTA 分析来构建理由。
注 3 :根据对硬件要素失效模式和它们对更高层面的影响的认知,这种评估可能是硬件要素的全局诊断覆盖率,或更详细的失效模式的覆盖率评估。
注 4 :附录 D 可以作为起始点,为已制定的安全机制确定诊断覆盖率。所声明的诊断覆盖率需要合适的理由支持(见 GB / T34590. 10 — 2022 残余失效率评估条款和 GB/ T34590.11 — 2022 附录 A 中的示例)。
注 5 :本要求适用于硬件、软件或两者结合实现的安全机制。

GB / T34590. 10 — 2022 8. 1. 3 残余故障
该故障或该故障的一部分:
———可直接导致违背安全目标;
———并且是硬件要素的故障,对于该硬件要素,有至少一个安全机制预防其某些违背安全目标的故障或者该故障的一部分。
示例:如果仅用 RAM 棋盘格检测的安全机制来检查随机存储器( RAM )模块,那么不能探测出某些种类的桥接故障。因这些故障导致的对安全目标的违背不能被安全机制所预防。这些故障即为残余故障。
注:上述示例中安全机制的诊断覆盖率小于 100% 。

GB/ T34590.11 — 2022 附录 A 中的示例

A. 1 DMA 安全机制评估示例

A. 1. 1 用例描述

以下是此示例中考虑的 DMA 用例:
———通信外设每隔 X 毫秒接收一条消息;
———一旦消息被通信外设接收,它就触发 DMA 请求;
——— DMA 将消息从外设接收缓冲区传输到 RAM 区域;
———总是传输到相同的 RAM 区域,独立于消息内容;
——— DMA 完成传输后,会触发一个 CPU 中断;
——— CPU 根据消息 ID 将消息复制到 RAM 中的另一个缓冲区。

A1. 2 安全机制的描述

在此示例中,下列安全机制可用于监控 DMA 活动是否正确。
——— SafMech _ 01 _ DMA _ MPU :定义可通过 DMA 访问的存储器区域的专用存储器保护单元:
● 写访问仅限于目标地址;
● 读取访问仅限于源地址。
——— SafMech _ 02 _ E2E _ Protection :
● DMA 传输的消息采用以下机制进行端到端保护:
覆盖数据内容、消息 ID 和消息计数器的 8 位 CRC ;
消息 ID ( 4 位);
消息计数器(
4 位);
● 在 2
4 =16 个消息 ID 中,只有 12 个 ID 是有效的;
● 计数器达到最大值 0xF 后重置为零;
● 接收到数据传输完成信号后, CPU 将消息复制到另一个 RAM 区域。 DMA 无法访问此存储区域。在 CPU 执行复制操作之后,检查 E2E 保护机理。应用程序只使用此副本,不使用 DMA 的目标地址中的数据。
——— SafMech _ 03 _ Timeout _ Mon :数据传输应该是周期性的,系统知悉数据传输的频率,从而监测
在规定时间范围内是否有数据传输发生。
——— SafMech _ 04 _ IR _ Source _ Mon :在中断请求的情况下,这个安全机制将检查触发是否来自合
法源。

A. 1. 3 失效模式的定义和诊断覆盖率的估算。根据描述的用例和安全机制,定义了 A.
1. 3. 1~A. 1. 3. 4 的失效模式,并可以估算以下诊断覆盖率
的值。

A. 1. 3. 1 DMA _ FM1 :请求的数据传送未发生
由于在指定的时间范围内没有数据传输完成信号,此失效模式可以被 SafMech _ 03 _ Timeout _ Mon探测到。 FMC
DMA _ FM1 估算为 100% 。

A. 1. 3. 2 DMA _ FM2 :没有请求,但发生了数据传输DMA 将数据从源地址传送到目标地址。其指示了数据传输的完成。取决于源地址的内容,传输的数据可能是以前的消息( DMA _ FM2.1 )或随机值( DMA _ FM2. 2 ;“白噪声”模型,即每个可能的错误状态都是等概率的)。
更多详情如下。
——— DMA _ FM2.1 :通过 E2E 保护机制( SafMech _ 02 _ E2E _ Protection )中的消息计数器或消息 ID可以检测是否是之前的消息。 FMC DMA _ FM2。1 估算为 100% 。
——— DMA _ FM2.2 :在随机值的情况下:
● 随机匹配合法 CRC 值的概率 p CRC ,legal 为 1 / 2^8;
● 随机匹配合法 ID 的概率 p ID ,legal 为 12 / 16 ;
● 随机匹配正确计数器值的概率 p Counter ,legal 为 1 / 2^4 (因为 2^4个值中只有一个值是正确的);
● 未触发错误的总体概率 p RF 为 p RF = p CRC ,legal× p ID , legal× p Counter , legal=0. 000183 ;
● FMC DMA _ FM2. 2 估算为 1- p RF ,因此等于 99. 98% 。
为了准确估计总体失效模式覆盖率,本文件对两种失效模式 DMA _ FM2.1 和 DMA _ FM2. 2 之间的失效模式分布进行了估算。
由于这两个值都很高并且非常接近,因此忽略了对这两种失效模式分布的估算,并且仅使用较低的值:
FMC DMA _ FM2 和 FMC DMA _ FM2. 2 估算值为 99. 98% 。

A. 1. 3. 3 DMA _ FM3 :数据传输过早/过晚
为了评估,更详细的失效模式如下。
——— DMA _ FM3.1 :在正确请求之前触发数据传输。此失效模式等同于 DMA _ FM2 ,此处不再进一步评估。 FMC
DMA _ FM3. 1 估算为 100% 。
——— DMA _ FM3.2 :在正确的请求之后过晚触发数据传输。根据延迟的不同,其影响可能是下列情况之一。
● DMA _ FM3.2a :根据通信外设不同,消息可能在被 DMA 提取之前被后续消息覆盖,或者可能无法接收到后续消息。这两种情况都会导致消息丢失。这种情况可以被 SafMech _ 03_ Timeout _ Mon 或 SafMech _ 02 _ E2E _ Protection (通过消息计数器)探测到,且 FMC=100% 。取决于通信外设,其本身可以产生附加的错误信号。
● DMA _ FM3.2b :在 DMA 获取消息期间,通信外设接收到下一个消息并部分覆盖前一个消息。这将造成一个损坏的消息,其内容由前后两个消息的部分组成。
a ) ID 是合法的( p ID , legal=1 )。
b ) 当前消息的计数器值在很高的概率下可能与前一个消息的计数器值相同(如果两个消息具有相同的传输频率)。这里假设最坏情况的概率为 p Counter ,legal=1 。
c ) 将数据损坏模型化为“白噪声”,生成随机匹配合法 CRC 值的概率 p CRC , legal 为 1 / 2^8 。
d ) FMC=1- p CRC , legal× p ID , legal× p Counter , legal=99. 6% 。
e ) 取决于通信外设:可以生成附加的错误信号,增加有效的 FMC ;或此失效模式不可能
发生,失效模式只有 DMA _ FM3.2a 。
为了准确估算 FMC DMA _ FM3.2 ,需要推导 DMA _ FM3. 2a 和 DMA _ FM3. 2b 的失效模式分布。对于保
守的初次估算,可以使用两者中较低的 FMC : FMC DMA _ FM3.2 =99. 6% 。
——— DMA _ FM3.3 :在传输完成之前发出传输完成信号。这将导致一个消息的部分损坏,其目标缓冲区中的消息由两个消息混合组成。就 SafMech _ 02 _ E2E _ Protection 的探测而言,可以证明FMC DMA _ FM3. 3 的估算值类似于 DMA _ FM3. 2b ,为 99. 6% 。
—— DMA _ FM3.
4 :传输完成后,数据传输完成的信号提供过晚。这种失效模式会导致:
● DMA _ FM3.4a :在被 CPU 提取之前,该消息被后续的消息覆盖。这会导致消息丢失,该失效可以被 SafMech _ 03 _ Timeout _ Mon 或 SafMech _ 02 _ E2E _ Protection 探测到,且 FMC=100% 。这类似于 DMA _ FM3. 2a 。
● DMA _ FM3.4b :在被 CPU 提取期间,该消息被 DMA 覆盖。这会导致消息部分损坏。FMC =99. 6% (类似于 DMA _ FM3. 2b )。按照与之前相同的证明,FMC DMA _ FM3. 4 总体值可估算为 99. 6% 。

A. 1. 3. 4 DMA _ FM4 :错误输出
和先前与时序相关的失效模式相比,该失效模式属于时序正确但是输出不正确的问题。在此示例中, DMA 具有以下输出:
———控制信号:读取或写入;
———控制信号:访问宽度(8 位、 16 位、 32 位);
———控制信号:要访问的地址;
———数据(在写入的情况下);
———四种不同的中断请求信号。
可区分出以下子类别的失效模式。
——— DMA _ F4.
1a :写入操作被执行为读取操作。
——— DMA 对 RAM 目标地址的写入操作被执行为对该地址的读取访问。该消息将不会被更新。完成“传输”之后,DMA 仍然会触发 CPU 中断请求。 SafMech _ 02 _ E2E _ Protection 通过检查ID 或计数器值的方式探测到这是一条旧消息。此外, SafMech _ 01 _ DMA _ MPU 会探测到非法访问(写入操作被误执行为读取操作)。 FMC DMA _ FM4.1A 估算为 100% 。
——— DMAF4.1b :读取操作被执行为写入操作。
读取操作被执行为写入操作: DMA 对通信外设的读取访问被执行为写入操作。根据通信外设的不同,这可能会导致通信外设的错误响应。此外,SafMech _ 01 _ DMA _ MPU 将探测到非法的写访问。 FMCDMA _ FM4. 1b 估算为 100% 。
——— DMA _ F4.2 :错误的访问宽度。
错误的访问宽度:此失效模式将导致消息损坏,可通过 SafMech _ 02 _ E2E _ Protection 的 CRC探测到。通过 ID 检查和非法的消息计数器值也可以探测到该错误(见 SafMech _ 01 _ DMA _MPU )。 FMC DMA _ FM4. 2 估算为 99. 6% 。
——— DMA _ F4.3 :错误的访问地址。错误的访问地址:此失效模式将导致 DMA 访问非法地址,并将被 SafMech _ 01 _ DMA _ MPU
探测到。 FMC
DMA _ FM4. 1b 估算为 100% 。
——— DMA _ F4.
4 :错误的数据输出。
错误的数据输出:该失效模式将导致消息的随机损坏,类似于 DMA _ FM2. 2 。 FMC DMA _ FM4. 4 估
算为 99.
98% 。
——— DMA _ F4.
5 :错误的中断请求。
错误的中断请求:在此示例中, DMA 只触发一个 CPU 中断请求。因此 SafMech _ 04 _ IR _
Source _ Mon 将探测到此故障。 FMC DMA _ FM4. 5 估算为 100% 。

7. 4. 3. 5 如果适用,应按照 GB / T34590. 9 — 2022 第 7 章进行相关失效分析,提供证据证明设计中的硬件要素与它们的独立性要求相符合。
注 1 :见 GB / T34590.9 — 2022 附录 C 。
注 2 :见 GB / T34590.11 — 2022 中 4. 7 。

GB / T34590.9 — 2022 附录 C

识别相关失效的框架
两个或多个要素之间的独立性通过证明不存在相关失效来确定,即不存在级联失效和共因失效。根据安全概念,例如,为了支持 ASIL 分解,可能要求要素之间有独立性。
为了识别级联和共因失效,可以使用图 C.1 所示的耦合因素类别来提高分析的完整性。

如表 C. 1 所示,这些耦合因素类别可以作为检查清单应用于任何开发层面,包括系统、软件、硬件和半导体层面。表 C.1 提供了耦合因素的示例,这些示例可逐一映射到 7. 4. 4 中的内容。一些例子可以属于多个耦合因素类别,例如,软件标定参数可以被视为共享资源或共享信息输入。

GB / T34590.11 — 2022 中 4. 7

7. 4. 3. 6 如果硬件设计引入了新危害,且这个危害没有被现有的 HARA 报告覆盖,则应按照GB / T34590. 8 — 2022 第 8 章中的变更管理流对它们进行引入和评估。
注:新识别出的、没有被现有安全目标覆盖的危害,通常是非功能性的危害。非功能性的危害在 GB / T34590 范围之外,但在危害分析和风险评估中能对它们添加如下注释,“由于不在 GB / T34590 的范围内,所以没有对该危害指定 ASIL 等级”。然而,也能指定一个 ASIL 等级作参考。

7. 5. 3 硬件设计验证报告,由 7. 4. 4 的要求得出。

7. 4. 4 硬件设计的验证

7. 4. 4. 1 应按照 GB / T34590. 8 — 2022 第 9 章来验证硬件设计,并按照表 3 中列出的硬件设计验证方法
提供证据证明：

a ) 满足硬件安全要求;

b ) 与软硬件接口规范兼容;

c ) 用来在生产和服务过程中实现功能安全的安全相关特殊特性的适用性。

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

7. 4. 4. 2 方法 1a 和 1b 检查硬件设计中硬件安全要求是否得到完整和正确的执行。在硬件设计过程中,如果发现任何硬件安全要求的实施是不可行的,应按照 GB / T34590.8 — 2022 第 8 章中的变更管理流程提出变更请求。

GB / T34590.8 — 2022 第 8 章

8. 5. 1 变更管理计划,由 8. 4. 1 的要求得出。

8. 4. 1 计划和启动变更管理

8. 4. 1. 1 在对工作成果进行变更前,应计划和启动变更管理流程。
注:配置管理和变更管理是相互关联的,定义并维护两个流程间的接口,以确保变更管理的有效性。

8. 4. 1. 2 应在变更管理计划中识别要进行变更管理的工作成果、相关项和要素,这些工作成果、相关项和要素也要满足 7.4. 3 的要求。

8. 4. 1. 3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表

8. 4. 1. 4 变更管理流程应包括:

a ) 变更需求,按照 8. 4. 2 ;

b ) 变更需求分析,按照 8. 4. 3

c ) 变更需求的决策和依据,按照 8. 4. 4 ;

d ) 已接受的变更的实施和验证,按照 8. 4. 5 ;

e ) 文档化,按照 8. 4. 5 。

注 1 :变更管理流程可适用于开发过程中的相应阶段。
注 2 :可在一个变更需求中处理多个变更。

8. 5. 2 变更需求,由 8. 4. 2 的要求得出。

8. 4. 2 变更需求

8. 4. 2. 1 应为每个变更需求分配唯一的识别码。

8. 4. 2. 2 每个变更需求应至少包含以下信息:

a ) 日期;

b ) 所需变更的理由;

c ) 所需变更的准确描述;

d ) 所需变更基于的配置。

8. 5. 3 影响分析和变更需求计划,由 8. 4. 3 和 8. 4. 4 的要求得出。

8. 4. 3 变更需求分析

8. 4. 3. 1 对于每个变更需求,应针对以下信息,对所涉及的相关项或要素、接口及关联相关项或要素进
行影响分析:

a ) 变更需求的类型;
示例:可能的变更类型有解决错误、调整、消除、加强、预防。

b ) 对需更改的工作成果、相关项和要素及受影响的工作成果、相关项和要素进行的识别;

c ) 在分布式开发的情况下,所涉及的相关方的识别及其责任;

d ) 变更对功能安全的潜在影响;

e ) 变更的实现和验证的日程表。

8. 4. 3. 2 对工作成果的每次变更,应重新启动安全生命周期的适用阶段。后续阶段的开展应符合GB / T34590 。

8. 4. 4 变更需求评估

8. 4. 4. 1 应使用按照 8. 4. 3. 1 进行的影响分析的结果,对变更需求进行评估,并且应由授权人员决定是否接受、拒绝或推迟变更。
示例:典型的授权的人员包括:
———项目经理;
———安全经理;
———负责质量保证的人员;
———涉及的开发人员。
注:已接受的变更需求可按优先级排序,并与已接受的相关变更需求合并。

8. 4. 4. 2 对于每个已接受的变更需求,应决定由谁来开展变更及变更的最晚时间。该决定应考虑开展
变更时所涉及的接口。

8. 5. 4 变更报告,由 8. 4. 5 的要求得出。

8. 4. 5 变更的实施和记录

8. 4. 5. 1 应按计划实施变更和验证变更。

8. 4. 5. 2 如果变更影响了安全相关功能或特性,则应在发布相关项前,对按照 GB / T34590. 2 — 2022 中6. 4. 9 和 6. 4. 10 的功能安全评估和适用的认可评审进行更新。

GB / T34590. 2 — 2022 中6. 4. 9 认可措施

6. 4. 9. 1 相关项及其要素的功能安全应被认可,基于:

a ) 按照表 1 和 6. 4. 10 的要求,认可评审判断关键工作成果,即表 1 所列工作成果,能否提供充足并令人信服的证据,证明其对实现功能安全的贡献,此过程应考虑 GB / T34590 相应的目标和要求。
注 1 :对表 1 中规定的和安全计划中要求的工作成果进行认可评审。

b ) 按照表 1 和 6. 4. 11 ,功能安全审核判断功能安全所需的流程的实施情况;
注 2 : GB / T34590 中定义了功能安全所需的参考流程。与相关项或要素有关的流程通过安全计划中引用或规定的活动来定义。

c ) 按照表 1 和 6. 4. 12 ,功能安全评估判断相关项实现的功能安全,或所开发的要素对实现功能安全的贡献。
注 3 :表 1 中定义的独立性的目的是确保客观、公正的观点,避免利益冲突。本文中所用的“独立性”一词指的是组织独立性。
注 4 :认可措施指南见附录 D 。
注 5 :认可措施的结果报告包括所分析的工作成果或流程文档的名称和版本号(见 GB / T34590.8 — 2022 的第 10章)。
注 6 :如果在认可措施完成后,相关项发生变更,则需要重新进行或补充相关的认可措施(见 GB / T34590.8 — 2022的 8.4. 5. 2 )。
注 7 :认可措施,如认可评审和功能安全审核,可以与功能安全评估合并、联合,以支持相关项类似变型的处理。

6. 4. 9. 2 在相关项开发过程中,实施认可措施的人员应能接触开展安全活动的人员和组织机构,并应得到其支持。

6. 4. 9. 3 实施认可措施的人员应有权限获取相关信息和工具。

GB / T34590. 2 — 2022 中6. 4. 10 认可评审

6. 4. 10. 1 应按照 5. 4. 4 和 5. 4. 2. 7 的要求,为表 1 所列和安全计划中要求的各项认可评审指定负责人。该人员应提供一份报告,其中包含工作成果对功能安全所做贡献的判断。

6. 4. 10. 2 认可评审应在生产发布前完成。

6. 4. 10. 3 认可评审可基于对是否实现 GB / T34590 的相应目标来做判断。
注:为增加实现评审目标的置信度,评审员应对照 GB / T34590 的相应要求,检查工作成果的正确性、完整性、一致性、充分性和内容。

6. 4. 10. 4 按照 6. 4. 9. 2 和 5. 4. 4 ,可指定一名或多名助理支持认可评审的执行。这些人员可能缺乏与相应相关项、要素或工作成果有关的开发人员的独立性,但其独立性至少应为表 1 中定义的 I1 ,并且评审人员应评价其输入,以确保给出公正的意见。
注:由于认可评审是为了支持功能安全评估而进行的,如果适用,该任命和评价也可以在功能安全评估中进行评估。

6. 4. 10. 5 只要评审根据按照表 1 以足够的独立性进行,认可评审和验证评审就可以合并进行。

8. 4. 5. 3 变更的记录应包含以下信息:

a ) 按照第 7 章,在合适的层面下,变更的工作成果、相关项和要素的清单,包括配置和版本

b ) 开展的变更细节;

c ) 变更部署的计划日期。

注 1 :对临时变更需求,明确指出该变更需求的理由和变更持续的时间(如已知)。
注 2 :对被拒绝的变更需求,记录变更需求和拒绝的理由。

7. 4. 4. 3 应根据硬件安全要求和硬件设计规范验证用于开发集成到硬件中的 SEooC (独立于环境的安全要素)的假设的有效性。

7. 5. 4 与生产、运行、服务和报废相关的需求规范,由 7. 4. 5 的要求得出。

7. 4. 5 生产、运行、服务和报废

7. 4. 5. 1 如果安全分析表明安全相关的特殊特性与生产、运行、服务和报废相关,则应定义这些安全相关的特殊特性。安全相关的特殊特性的定义应包括:

a ) 生产和运行的验证措施;

b ) 这些措施的接受准则。
示例:对一种依赖于新的传感器技术的硬件设计的安全分析(例如,摄像头或雷达传感器),能揭示出这些传感器与
特殊安装流程的关系。这种情况下,在生产阶段对这些组件的额外验证措施可能是必要的。

7. 4. 5. 2 如果安全相关硬件要素的错误组装、拆卸和报废可能对实现或维护功能安全产生不利影响,则应该将避免错误执行所需的信息告知按照 GB / T34590.2 — 2022 第 7 章委任的负责生产、运行、服务和报废的人员。

7. 4. 5. 3 按照 GB / T34590. 7 — 2022 中的 5. 4. 1. 2 和 5. 4. 3. 3 ,安全相关硬件要素应可追溯。其目的是:

a ) 按照 GB / T34590. 2 — 2022 中的 7. 4. 2. 3 和 GB / T34590. 7 — 2022 中的 7. 4. 1. 1 进行有效的现场监测;

GB / T34590. 2 — 2022 中的7. 4. 2. 3 组织应建立、执行并维护流程以实现和保持相关项在生产、运行、服务和报废阶段的功能安全。
注:这包括与相关项功能安全相关的现场监控流程。参考 GB / T34590.7 — 2022 。

GB / T34590. 7 — 2022 中的 7. 4. 1. 1 应实施与相关项或其要素相关的潜在安全相关事件的现场监控流程,以便:

a ) 提供能用于分析以探测功能安全问题存在的现场数据;

b ) 分析现场数据,以探测功能安全问题的存在;

c ) 启动相关措施,来处理识别到的功能安全问题。

注 1 :现场监控数据可以提供按照 GB / T34590. 8 — 2022 中第 14 章的在用证明所需的证据,用于在其他环境中进行相关项或要素的后续发布。
注 2 :安全相关事件的现场监控过程包括决策过程、定义遏制和纠正措施(例如,召回)以及向利益相关者报告事件。利益相关者可以是组织内部的,如果是分布式开发,也可以是组织外部的。

7. 4. 5. 4 如果错误的服务可能对实现或维护功能安全产生不利影响,则应该将避免此类影响执行所需的信息告知按照 GB / T34590.2 — 2022 第 7 章委任的负责生产、运行、服务和报废的人员。

7. 4. 5. 5 硬件设计过程中产生的硬件要素的生产、运行、服务和报废要求,应告知按照 GB / T34590. 2 —2022 第 7 章委任的负责生产、运行、服务和报废的人员。

8 硬件架构度量的评估
8 Evaluation of the hardware architectural metrics

8. 5. 1 相关项架构应对随机硬件失效的有效性分析,由 8. 4. 1~8. 4. 8 的要求得出。

8. 4. 1 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应将按照附录 C 的诊断覆盖率、单点故障度量和潜伏故障度量的概念用于 8.4. 2~8. 4. 9 的要求。

8. 4. 2 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应结合残余故障和相关的潜伏故障来预估安全机制所实现的安全相关硬件要素的诊断覆盖率。
注 1 :附录 D 可以作为起始点,为已制定的安全机制确定诊断覆盖率。所声明的诊断覆盖率需要合适的理由支持(见 GB / T34590. 10 — 2022 残余失效率评估条款和 GB/ T34590.11 — 2022 附录 A 中的示例)。
注 2 :根据对硬件要素失效模式和它们对更高层面影响的认知,这种评估可能是一个硬件要素的诊断覆盖率评估,或更详细的失效模式的覆盖率评估。

GB/ T34590.11 — 2022 附录 A 中的示例

A. 1 DMA 安全机制评估示例

A. 1. 1 用例描述

A1. 2 安全机制的描述

A. 1. 3 失效模式的定义和诊断覆盖率的估算。根据描述的用例和安全机制,定义了 A.
1. 3. 1~A. 1. 3. 4 的失效模式,并可以估算以下诊断覆盖率
的值。

8. 4. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。分析中用到的硬件元器件预估失效率的确
定,应使用以下方法:

a ) 使用业界公认的硬件元器件失效率数据;或
示例 1 :用于确定硬件元器件失效率和失效模式分布的业界公认的来源包括 SN29500 、 IEC61709 、 MILHDBK217Fnotice2 、 RIACHDBK217Plus 、 UTEC80-811 、 NPRD — 2016 、 EN50129 : 2003AnnexC 、 RIACFMD — 2016 、 MILHDBK338 和 FIDESguide2009EdA 。例如,能使用由“ AlessandroBirolini- 可靠性工程”定义的失效模式分布。
注 1 :这些数据库给出的失效率数据一般都比较保守。
注 2 :在应用选定的业界数据源时,为避免人为降低所计算出的基础失效率,考虑以下因素:
———任务剖面;
———失效模式相对于运行条件的适用性;
———失效率单位(每工作小时或每日历小时)。

b ) 使用现场反馈的统计数据。这种情况下,预估的失效率宜有至少 70% 的可比置信度;或
注 3 :如果 SPFM 和 LFM 评估中使用的不同硬件元器件的故障率的置信度显著不同,则度量指标将是有偏差的。
注 4 :在将这些从现场反馈的基于统计的数据与不同置信度的其他数据源的值一起使用之前,可能仍然需要衡量这些数据。也可见注 7 。
注 5 :基于现场反馈的失效率能按照 GB / T34590.8 — 2022 第 14 章(在用证明)的描述进行计算。

c ) 使用工程方法形成的专家判断,该工程方法基于定量和定性的论证。应按照结构化准则进行专家判断,这些准则是判断的基础,应在失效率预估前进行设定。
注 6 :考虑到设计的新颖性,专家判断的准则可能包括由现场数据、测试、可靠性分析和基于物理失效仿真方法的启发式信息组合。
注 7 :能使用国际可靠性专家机构提供的资料: SAEJ1211 “鲁棒性验证” - 分析、建模和仿真提供了基于物理失效( PoF )的失效机制模型、JEDEC-JESD89 、 JEDEC-JESD91 、 JEDEC-JESD94 、 JEDEC-JEP143 和 JEDEC-JESD148 。
注 8 :如果失效率来自多个数据源(如在 8.4. 3 列举的)结合,例如,如果不同部件的失效率不能从同一来源获得,则能使用比例系数来缩放失效率,以便不同失效率的预测质量相等。如果可获得两个失效率源之间的比例系数的原理,则能使用这种比例。
示例 2 :只在一个数据源中发现要素失效率,而类似的要素在该源和另一个源中可用。比例系数是使用相同任务剖面的两个来源的失效率之比。
示例 3 :数据手册的失效率通常被认为是保守的。如果已选择与使用手册数据一致的随机硬件失效目标值,则能通过应用适当的比例系数,使用从现场反馈的失效率(例如,对应于比通常更保守的置信度)。
注 9 :如果没有合适的比例系数,则能将符合 SPFM 和 LFM 要求的单独目标值分配给所考虑的不同要素(类似于 8.4. 4 )。
注 10 :半导体指南见 GB / T34590.11 — 2022 中的 4. 6 。

8. 4. 4 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。如果能够提供的硬件元器件失效率证据不足,应提出替代方案(例如,增加安全机制来探测和控制此故障)。如果替代方法仅包括附加的以下安全机制:

a ) 对硬件元器件残余故障的诊断覆盖率应等于或高于相关项 SPFM 目标值;

b ) 对硬件元器件潜伏故障的诊断覆盖率应等于或高于相关项 LFM 目标值。
注 1 :例如,充分的证据可以指失效率是通过 8.4. 3 中列出的方法得到的。
注 2 :在确定安全机制的覆盖率时,能考虑硬件元器件的安全故障比例。在这种情况下,覆盖率的计算与单点故障度量或潜伏故障度量的计算方法类似,都是在硬件元器件层面而不是在相关项层面进行的。

8. 4. 5 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。对于每一个安全目标,由 GB / T34590. 4 —2022 中 6. 4. 5 要求的“单点故障度量( SPFM )”的定量目标值应基于下列参考目标值来源之一:

a ) 来自应用于值得信赖的相似设计中,对硬件架构度量的计算;或
注 1 :两个相似的设计有相似的功能和分配了相同 ASIL 等级的相似安全目标。

b ) 来自表 4 。
注 2 :此定量目标的目的是提供:
———设计指南;
———设计符合安全目标的证据。

GB / T34590. 4 — 2022 中 6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

8. 4. 6 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。对于每一个安全目标,由 GB / T34590. 4 —2022 中 6. 4. 5 要求的潜伏故障度量( LFM )的定量目标值应基于下列参考目标值来源之一:

a ) 来自应用于值得信赖的相似设计中,对硬件架构度量的计算;或
注 1 :两个相似的设计有相似的功能和分配了相同 ASIL 等级的相似安全目标。

b ) 来自表 5 。
注 2 :此定量目标的目的是提供:
———设计指南;
———设计符合安全目标的证据。

GB / T34590. 4 — 2022 中 6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

8. 4. 7 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标,对于每个安全目标,相关项的整体硬件应符合下列两者之一:

a ) 满足 8. 4. 5 中描述的“单点故障度量”目标值;或

b ) 满足在硬件要素层面规定的合适目标,这些目标足以符合分配给相关项整体硬件的单点故障度量的目标值(如 8.4. 5 中所描述的),并提供理由说明在硬件要素层面符合这些目标。

注 1 :如果相关项包含失效率等级有显著差异的不同种类的硬件要素,就会存在这样的风险,即为了满足硬件架构度量时仅关注具有最高等级失效率的那些硬件要素。一个可能发生此情况的例子是:只考虑线束、保险丝或接插件的失效率,而忽略失效率显著较低的硬件元器件的失效率,就以为实现了对单点故障度量的符合性。为每一类硬件规定合适的度量目标有助于规避这种不良影响。
注 2 :当瞬态故障与所用技术相关时,要考虑这些瞬态故障,能通过给它们指定并确认一个特定的“单点故障度量”目标值(如注 1 中解释的),或通过一个基于对内部安全机制有效性验证的定性理由来处理这类瞬态故障。
注 3 :如果不满足目标,将按 4.2 所述评估如何实现安全目标的理由。
注 4 :能结合考虑多个或所有适用的安全目标来确定单点故障度量;但在这种情况下,采用最高 ASIL 等级的安全目标的度量目标。

示例:如果一个相关项由三个硬件要素 A 、 B 和 C 组成,失效率分别为 λ A , λ B 和 λ C ,且 λ total = λ A + λ B + λ C ,则满足以下公式要素 SPFM 目标值 M LFM ,Element 的元素的任意组合是可接受的:

8. 4. 8 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。对于每个安全目标,相关项的整体硬件应该符合下列之一:

a ) 满足 8. 4. 6 中描述的“潜伏故障度量”目标值;或

b ) 满足在硬件要素层面规定的合适目标,这些目标足以符合分配给相关项整体硬件的潜伏故障度量的目标值(在 8.4. 6 中给出),并有理由说明在硬件要素层面符合这些目标;或

c ) 对于其故障可能导致安全机制(防止故障违背安全目标)无效的每个硬件要素,满足相关潜伏故障的诊断覆盖率目标值,该值与 8.4. 6 中给出的潜伏故障度量目标值一致(被当作诊断覆盖率),当每个安全机制都是基于故障探测且其无效可能导致违背安全目标时,适用此选项。

注 1 :列项 c )仅限于在每个相关项安全机制是基于故障探测的情况。在此情况下,通过这些安全机制的探测来警示目标功能的可能潜伏故障。在其他情况下,则只有选项 a )和 b )适用。
示例 1 :附录 H 提供了考虑潜伏故障处理的不同类型安全机制的示例。
注 2 :在列项 c )情况下,不计算度量,只评估安全机制对于硬件要素的潜伏故障的覆盖率。
注 3 :如果相关项包含失效率等级显著差异的不同种类的硬件要素,就会存在这样的风险,即为了满足硬件架构度量时仅考虑具有最高等级失效率的那些硬件要素。一个可能发生此情况的例子是,只考虑线束、保险丝或接插件的失效率,而忽略失效率显著较低的硬件元器件的失效率,就认为实现了对潜伏故障度量的符合性。为每一类硬件规定合适的度量目标值有助于规避这种不良影响。
注 4 :如果不满足目标,将按 4.2 所述评估如何实现安全目标的理由。
注 5 :可以结合考虑多个或所有适用的安全目标来确定潜在故障度量;但在这种情况下,采用最高 ASIL 等级的安全目标的度量目标。

示例 2 :如果一个相关项由三个硬件要素 A 、 B 和 C 组成,失效率分别为 λ A , λ B 和 λ C ,且 λ total = λ A + λ B + λ C ,则满足以下公式要素 LFM 目标值 M LFM ,Element 的任意组合是可接受的:

8. 5. 2 相关项架构应对随机硬件失效的有效性评估的验证评审报告,由 8. 4. 9 的要求得出。

8. 4. 9 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应按照 GB / T34590. 8 — 2022 第 9 章的要求,对应用 8.4. 7 和 8. 4. 8 中的方法得出的结果进行验证评审,以提供其技术正确性和完整性的证据。
注:验证单点故障度量,确保只考虑了安全相关硬件要素的失效率,这样度量才不会受到不具备单点故障或残余故障可能性的、不必要的安全相关硬件要素的影响(例如,向安全机制添加了不必要的硬件要素)。

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

9 随机硬件失效导致违背安全目标的评估
9 Evaluation of safety goal violations due to random hardware failures

9. 5. 1 由随机硬件失效导致违背安全目标的分析,由 9. 4. 2 或 9. 4. 3 的要求得出。

9. 4. 2 随机硬件失效概率度量( PMHF )的评估

9. 4. 2. 1 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。 9. 4. 2. 2 或 9. 4. 2. 3 要求的定量目标值应表述为相关项整个运行生命周期中每小时的平均概率。
注 1 :即使共用相同单位,失效率和相关项整个运行生命周期中每小时的平均失效概率是不同的值。
注 2 :运行生命周期仅包括实际工作时间。

9. 4. 2. 2 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应按照 GB / T34590. 4 — 2022 中 6. 4. 5 的要求,为随机硬件失效在相关项层面导致违背每个安全目标的最大可能性定义定量目标值,使用来源 a )、b )或 c )的参考目标值,如下所列:

a ) 来自表 6 ;

b ) 来自值得信赖的相似设计的现场数据;或

c ) 来自应用于值得信赖的相似设计中的定量分析技术(使用按照 8. 4. 3 的失效率)。
注 1 :这些来源于 a )、 b )或 c )的定量目标值没有任何绝对的意义,仅有助于将一个新的设计与已有设计相比较。其
目的是生成按照 9.1 描述的可用的设计指导,并获得设计符合安全目标的可用证据。
注 2 :两个相似的设计拥有相似的功能和分配了相同 ASIL 等级的相似安全目标。
注 3 :在没有其他来源的情况下,通常使用表 6 确定随机硬件失效的目标值。
注 4 :表 6 中的值适用于单一系统构成的相关项(例如,发动机控制系统、电子稳定性控制系统、电动助力转向系统、气囊约束系统)。
注 5 :表 6 中的目标值与手册的数据是保持一致的,是保守的。如果对由于随机硬件失效导致违背安全目标的评估是基于统计数据的(例如,来自现场数据),则能修改表 6 中给出的目标值,以避免为实现目标值而产生人为简化。

GB / T34590. 4 — 2022 中 6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

9. 4. 2. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。当一个相关项由多个系统构成时,根据9. 4. 2. 2 要求得出的目标值可以直接分配给构成该相关项的每一个系统。只要这些系统中的每一个都有可能违背相同的安全目标,并且相应的相关项目标值不会增加超过一个数量级,就可以应用此方法。
注 1 : 9.4. 2. 3 中所规定要求的可能性,例如,能用于新的更高级别功能所涉及的原有系统(例如,新的 ADAS 功能所使用的发动机管理系统、电子稳定性控制系统、电动助力转向系统或气囊约束系统),并且这些系统在以前的开发中达到了同样的安全目标。
示例:如果一个等级为 ASILD 的安全目标分配给由多个系统(最多 10 个)组成的相关项,其中每个系统都有可能违背该安全目标,则能将目标值 10-8 /h 分配给组成该相关项的每个系统。
注 2 :在附录 G 中给出了由两个系统组成的相关项 PMHF 预算分配的示例。

9. 4. 2. 4 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。针对单点、残余和多点故障的硬件架构定量分析,应提供证据证明 9.4. 2. 2 或 9. 4. 2. 3 要求的目标值已达到。此定量分析应考虑:

a ) 相关项的架构;

b ) 每个可导致单点故障或残余故障的硬件元器件的失效模式的估算失效率;

c ) 每个可导致多点故障的硬件元器件的失效模式的估算失效率;

d ) 安全机制对安全相关的硬件要素的诊断覆盖率;

e ) 多点故障情况下的暴露持续时间。

注 1 :在定量分析中,考虑可能导致一个安全相关的硬件要素及其安全机制同时失效的硬件要素失效模式。它们可能是单点故障、残余故障或多点故障。
注 2 :暴露持续时间从故障可能发生时开始,包括:
———与每个安全机制有关的多点故障探测时间间隔,或者当故障不对驾驶员显示(潜伏故障)时的车辆生命周期;
———单次行程的最长持续时间(对于驾驶员被要求以一种安全方式停车的情况);
———直到车辆进入车间维修前的平均时间间隔(对于驾驶员被警示要去维修车辆的情况)。
因此,暴露持续时间取决于涉及的监控类型(例如,连续监控、周期性自检、驾驶员监控、无监控)和探测到故障后的反应种类。对于连续监控触发向安全状态转移的情况,它可能短至几毫秒。当没有监控时,它可能长到车辆的生命周期。
对车辆去维修的平均时间的假设示例,取决于故障的类型:
———对舒适性功能的降级,
200 次车辆行程;
———对驾驶辅助功能的降级,
50 次车辆行程;
———对黄色警告灯或影响驾驶表现时,
20 次车辆行程;
———对红色警告灯,
1 次车辆行程。
通常不考虑维修所需要的时间(除了评估能暴露给维护人员的危害)。
一次车辆行程的平均时间间隔可能被认为等于:
———乘用车为 1h ;
——— T&B 车辆为 10h 。
注 3 :在大部分情况下,阶次高于二的多点失效对定量目标值的影响可以忽略。然而,在一些特定情况下(极高的失效率或差的诊断覆盖率),提供两个冗余的安全机制以达到目标可能是必要的。当技术安全概念是基于冗余的安全机制时,在分析中考虑阶次高于二的多点失效。
注 4 :附录 D 可以作为起始点,为已制定的安全机制确定诊断覆盖率。所声明的诊断覆盖率需要合适的理由支持(见 GB / T34590. 10 — 2022 残余失效率评估条款和 GB/ T34590.11 — 2022 附录 A 中的示例)。
注 5 :如 9.4. 2. 2 注 1 中所指出的, PMHF 值不具有绝对意义,但对于比较新设计与现有设计是有用的。
注 6 :如果 9.4. 2. 2 或 9. 4. 2. 3 中定义的目标值没有被满足,应按 4. 2 对给出的如何实现安全目标的论据进行评估。
这种论据可能基于:
———识别影响 PMHF 值的主要因素和覆盖率较低的失效模式;
———对这些因素进行评审,需考虑到其他准则的失效率、可靠性调查、诊断覆盖率、失效模式覆盖率、现场经验、验证措施、当前技术和专用措施(9. 4. 1. 2 中的注 2 列出了专用措施的示例)。
附录 F 中给出了这些论据的示例。
注 7 :基于对硬件要素失效模式及其在更高层面上后果的认知,评估可能是硬件要素的诊断覆盖率,或者更详细失效模式覆盖率的评估。
注 8 :由于相关项 PMHF 值推导过程中的不确定性(例如,失效率、失效模式、失效模式分布、诊断覆盖率、安全故障比例的推导),计算值可能会有很大变化,解释时需特别注意。

9. 4. 3 对违背安全目标的每个原因的评估( EEC）（大多数企业都会选择PMHF，所以在此就不展开介绍）

9. 5. 2 硬件专用措施的定义,如果需要,包括专用措施有效性的依据,由 9. 4. 1. 2 和 9. 4. 1. 3 的要求得出。

9. 4. 1. 2 本要求适用于等级为 ASILC 和 D 的安全目标。单一硬件元器件单点故障只有在提供有效论据证明其发生概率足够低时才能考虑接受,这些论据包括以下选项中的一个。

a ) 采取专用措施;或

b ) 对于 ASILD 等级安全目标,需要满足以下准则:
———采用保守的数据来源;
———只有一小部分的失效率能够违背安全目标(例如,一个特殊的失效模式);
———得出的单点故障失效率小于失效率等级 1 对应失效率的十分之一(按照 9.4. 3. 3 )。

c ) 对于 ASILC 等级安全目标,需要满足以下准则:
———采用保守的数据来源;
———只有一小部分的失效率能够违背安全目标(例如,一个特殊的失效模式);
———得出的残余故障失效率小于失效率等级 2 对应失效率的十分之一(按照 9.4. 3. 3 )。
注 1 :针对本条要求,微控制器、专用集成电路( ASIC )或相似的片上系统( SoC )均能看作硬件元器件。
注 2 :专用措施可能包括:
a ) 设计特征,如硬件元器件过设计(例如,电气或热应力等级)或者物理隔离(例如,印刷电路板上的触点间隔);
b ) 专门的来料抽样测试,以降低此失效模式发生的风险;
c ) 老化测试;
d ) 作为控制计划一部分的专用控制设备;
e ) 安全相关的特殊特性的分配。

9. 4. 1. 3 本要求适用于等级为 ASILC 和 D 的安全目标。如果一个硬件元器件的残余故障诊断覆盖率低于 90% ,只有在提供有效论据证明其发生概率足够低时才能考虑接受,这些论据包括以下选项中的一个。

a ) 采取专用措施( 9. 4. 1. 2 中注 2 列举的专用措施示例)。

b ) 对于 ASILD 等级安全目标,需要满足以下准则:
———采用保守的数据来源;
———只有一小部分的失效率能够违背安全目标(例如,一个特殊的失效模式);
———得出的残余故障失效率小于失效率等级 1 对应失效率的十分之一(按照 9.4. 3. 3 )。

c ) 对于 ASILC 等级安全目标,需要满足以下准则:
———采用保守的数据来源;
———只有一小部分的失效率能够违背安全目标(例如,一个特殊的失效模式);
———得出的残余故障失效率小于失效率等级 2 对应失效率的十分之一(按照 9.4. 3. 3 )。
注 1 :针对本条要求,能把一个微控制器、一个专用集成电路或相似的片上系统看作硬件元器件。
注 2 :当确定安全机制的覆盖率时,能考虑硬件元器件安全故障的比例。在这种情况下,覆盖率的计算与单点故障度量的计算类似,但仅在硬件元器件层面,而不在相关项层面。

9. 5. 3 对随机硬件失效导致违背安全目标进行评估的验证评审报告,由 9. 4. 4 的要求得出。

9. 4. 4 验证评审

本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应对要求组 9.4. 2 或 9. 4. 3 得出的分析进行验
证评审,按照 GB / T34590.8 — 2022 第 9 章提供其技术正确性和完整性的证据。

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

10 硬件集成和验证
10 Hardware integration and verification

10. 5. 1 硬件集成和验证规范,由 10. 4. 1~10. 4. 6 的要求得出。

10. 4. 1 硬件集成和验证活动应按照 GB / T34590. 8 — 2022 第 9 章执行

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

10. 4. 2 硬件集成和验证应与 GB / T34590. 4 — 2022 中 7. 4. 1 规定的集成规范与测试策略相协调。
注:如果已采用 GB / T34590.9 — 2022 第 5 章中定义的 ASIL 等级分解,已分解要素所对应的集成活动和其后的活动都要采用分解前的 ASIL 等级。

GB / T34590. 4 — 2022 中 7. 4. 1 集成和测试策略规范

7. 4. 1. 1 为了提供证据证明系统架构设计符合功能安全和技术安全要求,应按照 GB / T34590. 8 — 2022第 9 章进行集成测试活动,以检查:

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

a ) 功能安全及技术安全要求的正确实施;

b ) 安全机制正确的功能性能、准确性和时序

c ) 接口的一致性和正确实施;

d ) 足够的鲁棒性。

7. 4. 1. 2 应考虑系统架构设计规范、功能安全概念和技术安全概念,定义集成和测试策略,其应该述及

a ) 适合提供功能安全证据的测试目标;

b ) 相关项及该相关项中有助于安全概念的要素的集成和测试。
注:这包括有助于安全概念的其他技术要素。

7. 4. 1. 3 为使相关项集成子阶段能够进行,应根据集成和测试策略执行以下内容

a ) 应为软硬件集成和测试定义相关项集成和测试策略;

b ) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件验证的未解决问题得到处理;

c ) 相关项集成和测试策略应考虑车辆系统(相关项内部和外部)与环境之间的接口;

d ) 相关项集成和测试策略应考虑被集成的系统或要素是否是作为独立于环境的安全要素(SEooC )进行开发,以及开发期间所做的假设是否需要验证。
注:在软硬件集成层面和相关项层面进行集成与验证的规范,要考虑软硬件之间的接口及其交互。

7. 4. 1. 4 如果系统是可配置的(如通过要素的变量或标定数据),在系统或整车层面的验证应提供证据证明用于量产实施层面的配置符合安全要求。
注:测试一个合适的配置子集可能是足够的。

7. 4. 1. 5 在整个集成子阶段,对每个功能安全和技术安全要求是否得到了满足,应至少进行一次验证(如果适用,通过测试来验证)。
注 1 :一个常规的做法是在更高一级的集成层面上对已定义的安全要求进行验证。
注 2 :当一个 SEooC 集成到一个安全相关系统中,其开发中使用的假设的有效性需要进行验证。
注 3 :集成测试期间识别出的安全异常按照 GB / T34590.2 — 2022 中 5. 4. 3 的要求进行报告。

7. 4. 1. 6 为了恰当地定义集成测试的测试用例,应考虑集成的层面,使用表 3 中所列的恰当的方法组合导出测试用例。

10. 4. 3 安全相关硬件元器件应按照基于国际质量标准或同等的公司标准而充分建立的完善流程进行鉴定。
示例:按照 ISO16750 、 AEC-Q100 或 AEC-Q200 ,对电子元器件进行鉴定。

10. 4. 4 提供证据证明,对于选定硬件集成测试已定义适当的测试用例,测试用例应使用表 10 中所列方法的适当组合来导出。

10. 4. 5 硬件集成和验证活动应当验证硬件安全要求实施的完整性和正确性。为了达到这些目的,应考虑表 11 所列方法。

10. 4. 6 硬件集成和验证活动应验证硬件在环境和运行应力因素下的耐用性和鲁棒性。为了达到该目的,应考虑表 12 所列方法。

10. 5. 2 硬件集成和验证报告,由 10. 4. 1~10. 4. 6 的要求得出。

10. 4. 1 硬件集成和验证活动应按照 GB / T34590. 8 — 2022 第 9 章执行

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

GB / T34590. 4 — 2022 中 7. 4. 1 集成和测试策略规范

7. 4. 1. 1 为了提供证据证明系统架构设计符合功能安全和技术安全要求,应按照 GB / T34590. 8 — 2022第 9 章进行集成测试活动,以检查:

GB / T34590. 8 — 2022 第 9 章

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。

f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备

g ) 如果适用,用于验证的资源;

h ) 当探测出异常时需采取的行动;

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。

d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。

e ) 输入数据,数据时序及其值;

g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审。

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

a ) 功能安全及技术安全要求的正确实施;

b ) 安全机制正确的功能性能、准确性和时序

c ) 接口的一致性和正确实施;

d ) 足够的鲁棒性。

7. 4. 1. 2 应考虑系统架构设计规范、功能安全概念和技术安全概念,定义集成和测试策略,其应该述及

a ) 适合提供功能安全证据的测试目标;

b ) 相关项及该相关项中有助于安全概念的要素的集成和测试。
注:这包括有助于安全概念的其他技术要素。

7. 4. 1. 3 为使相关项集成子阶段能够进行,应根据集成和测试策略执行以下内容

a ) 应为软硬件集成和测试定义相关项集成和测试策略;

b ) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件验证的未解决问题得到处理;

c ) 相关项集成和测试策略应考虑车辆系统(相关项内部和外部)与环境之间的接口;

7. 4. 1. 6 为了恰当地定义集成测试的测试用例,应考虑集成的层面,使用表 3 中所列的恰当的方法组合导出测试用例。

10. 4. 4 提供证据证明,对于选定硬件集成测试已定义适当的测试用例,测试用例应使用表 10 中所列方法的适当组合来导出。

10. 4. 5 硬件集成和验证活动应当验证硬件安全要求实施的完整性和正确性。为了达到这些目的,应考虑表 11 所列方法。

10. 4. 6 硬件集成和验证活动应验证硬件在环境和运行应力因素下的耐用性和鲁棒性。为了达到该目的,应考虑表 12 所列方法。

ISO26262-Part4
Product development at the system
level

6 技术安全概念工作成果

6. 5. 1 技术安全需求规范,由 6. 4. 1 和 6. 4. 2 的要求得出。

6. 4. 1 技术安全要求的定义

6. 4. 1. 1 技术安全要求应按照功能安全概念、相关项的系统架构设计来定义,考虑如下:
a ) 相关项、系统及其要素安全相关的关联性及约束条件;
b ) 系统的外部接口,如果适用;
c ) 系统可配置性。
注 1 :设计约束可能来自于:环境条件、安装空间、实施本身(例如可用性能、热容量、热扩散)以及其他功能或非功能性要求(例如安全性、所用技术的物理限制)。
注 2 :系统的可配置性由系统要素中的变量、配置数据或标定数据来确定,通常作为将现有系统复用于不同应用的策略的一部分。

6. 4. 1. 2 技术安全要求应定义系统对影响安全要求实现的激励的响应。这包括在各种相关运行模式和所定义的系统状态下,激励与失效的组合。
示例:如果收到的 ACC 指令信息未通过错误检测代码检查,则制动系统电控单元( ECU )将禁用自适应巡航控制( ACC )制动。

6. 4. 1. 3 除技术安全要求已定义的那些功能外,如果其他功能或要求也由该系统或其要素实现,则应定义这些功能或要求,或者参考其规范。
示例:其他要求可能来自联合国欧洲经济委员会( UN / ECE )法规、美国汽车安全技术法规(FMVSS )、公司平台战略、功能概念或其他概念,例如信息安全概念

6. 4. 1. 4 技术安全要求和非安全要求不应矛盾。

6. 4. 2 安全机制

6. 4. 2. 1 技术安全要求应定义安全机制,用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求(见 GB / T34590. 3 — 2022 第 7 章)的失效,包括:
a ) 与系统自身故障的探测、指示和控制相关的安全机制;
注 1 :包括用于探测随机硬件故障及探测系统性故障(如果适用)的系统自身监控。
注 2 :包括对通信通道失效(例如:数据接口、通信总线、无线射频链接)的探测和控制的安全机制。
注 3 :可以在系统架构适当的层级定义安全机制。
b ) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制;
示例:外部设备包括其他的电控单元、电源或者通信设备。
c ) 使系统实现或者维持在相关项的安全状态的安全机制;
注 4 :包括来自安全机制的多个控制请求的仲裁。
d ) 定义和执行报警和降级策略的安全机制;
e ) 防止故障处于潜伏故障的安全机制。
注 5 :如同 a ) ~d ),这些安全机制通常与上电过程(运行前检查)、运行中、下电过程(运行后检查)及维护过程中发生的自检相关。

6. 4. 2. 2 对于每个使相关项实现安全状态或维持安全状态的安全机制,应定义下列内容:
a ) 状态间的转换;
注 1 :包括控制执行器的要求。
b ) 与从适当的架构层级分配得到的时间要求相关的故障处理时间间隔;
注 2 :该子要求的目的是在针对每个安全目标定义的故障处理时间间隔的范围内,实现时间一致。
c ) 不能在 FTTI 内进入相关项安全状态时的紧急运行容错时间间隔(见 GB / T34590. 1 — 2022 中的3. 45 )。
注 3 :整车测试和试验能够用于确定紧急运行容错时间间隔。
示例 1 :安全状态之前的降级运行持续时间。
示例 2 :一个依赖于电源的线控制动应用的安全机制,可以包括定义备用电源或储能设备(容量、启动和运行时间等)。

6. 4. 2. 3 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。如果适用,应定义安全机制,以防止故障处于潜伏故障。
注 1 :仅随机硬件故障的多点故障有可能成为潜伏故障。
示例:自检可作为检测多点故障的安全机制。用于验证组件在不同运行模式(例如上电、下电、运行或额外的自检模式)下的状态。阀、继电器或灯在常规上电时进行的功能检测就是自检的例子。
注 2 :识别是否需要防止故障处于潜伏状态的安全机制的评估标准来源于良好的工程实践。 GB / T34590. 5 — 2022 第 8 章给出的潜伏故障度量提供了评估标准。

6. 4. 2. 4 此要求适用于 ASIL ( A )、( B )、 C 和 D 等级。为了避免多点失效,应为每个探测多点故障的安全机制定义诊断测试策略,包括:
a ) 硬件组件的可靠性要求,并考虑其在架构中的角色及其对多点失效的贡献;
b ) 定义的量化目标值,表征由于随机硬件失效而违背各安全目标的最大可能性(见 GB / T34590. 5 — 2022 第 9 章);
c ) 已分配的 ASIL 等级,从相关安全目标、功能安全要求或更高层面的技术安全要求中导出;
d ) 多点故障探测时间间隔。
注 1 :诊断测试策略可以是时间驱动(例如使用诊断测试时间间隔)或者事件驱动(例如启动测试)。
注 2 :二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。
注 3 :下列措施的使用取决于时间约束:
———系统或要素在运行过程中的周期性测试;
———要素在上下电时的自检;
———系统或要素在维护时的测试。

6. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应至少符合:
a ) ASILB 等级(对于分配为 ASILD 等级的技术安全要求);
b ) ASILA 等级(对于分配为 ASILB 等级和 ASILC 等级的技术安全要求);
c ) QM 等级(对于分配为 ASILA 等级的技术安全要求)。
注:如果安全要求运用了 ASIL 等级分解,那么本章的要求亦适用于分解后的要求。
示例:某内存存储采用奇偶校验作为安全机制,其安全要求被评为 ASILB 等级。针对用于测试该奇偶校验机制在探测和指示内存故障的能力的自检测试,其要求可被评为 ASILA 等级。

6. 5. 2 技术安全概念,由 6. 4. 3~6. 4. 6 的要求得出。

6. 4. 3 系统架构设计规范和技术安全概念

6. 4. 3. 1 技术安全概念和该子阶段的系统架构设计应基于相关项定义,功能安全概念和先前的系统架构设计。

6. 4. 3. 3 系统架构设计应实现技术安全要求。

6. 4. 3. 4 关于技术安全要求的实现,系统架构设计应考虑:
a ) 验证系统架构设计的能力;
b ) 与实现功能安全相关的预期软硬件要素的技术能力;
c ) 在系统集成过程中执行测试的能力。

6. 4. 3. 5 应定义安全相关要素的内部和外部接口,其他要素不应对安全相关要素产生不利的安全相关影响。

6. 4. 3. 6 如果在系统架构设计期间对安全要求进行 ASIL 等级分解,应按照 GB / T34590. 9 — 2022 第 5 章进行。

6. 4. 4 安全分析及避免系统性失效

6. 4. 4. 1 应按照表 1 和 GB / T34590. 9 — 2022 第 8 章进行系统架构设计的安全分析,其目的在于:
———为系统设计的适合性提供证据,以证明其适合提供与 ASIL 等级相适应的特定安全相关功能和特性;
———识别失效原因和故障影响;
———识别或确认安全相关系统要素和接口;
———支持设计规范,并基于已识别的故障原因和失效影响验证安全机制的有效性。
注 1 :安全相关特性包括独立性和免于干扰的要求。
注 2 :这些分析的目的是辅助设计。因此在该阶段,定性分析是足够的。如果有必要,采用定量分析。
注 3 :在足以识别随机硬件失效和系统性失效的原因和影响的细节层面上进行分析。
注 4 :演绎和归纳的方法结合使用的目的是提供互补的分析方法,见 GB / T34590. 9 — 2022 中的 8. 2 。

6. 4. 4. 2 为符合安全目标或要求,应消除已识别出的引起失效的内部原因,或在必要时减轻它们的影响。

6. 4. 4. 3 为符合安全目标或要求,应消除已识别出的引起失效的外部原因,或在必要时减轻它们的影响。

6. 4. 4. 4 为了减少系统性失效的可能性,宜在适用处应用值得信赖的系统设计原则。这些原则可能包括:
a ) 值得信赖的技术安全概念的复用;
b ) 值得信赖的要素设计的复用,包括硬件和软件组件;
c ) 值得信赖的探测和控制失效的机制的复用;
d ) 值得信赖的或标准化接口的复用。

6. 4. 4. 5 应对值得信赖的设计原则的适用性进行分析并形成文档,以确保其和最终产品应用的一致性和适用性。

6. 4. 4. 6 为了避免系统性故障,系统架构设计应具有以下特征:
a ) 模块化;
b ) 适当的颗粒度水平;
c ) 简单。
注:可以通过使用诸如分层的设计,精确的接口定义,避免组件和接口不必要的复杂性,可维护性和可验证性之类的设计原则实现上述特征。

6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 1 应按照 6. 4. 3 中的系统架构设计,定义探测、控制或减轻随机硬件失效的措施。
示例 1 :这些措施可能是硬件的诊断特性,通过软件对其的使用来探测随机硬件失效。
示例 2 :随机硬件失效发生时,不需要探测即可进入安全状态的硬件设计(即:失效 - 安全的硬件设计)。
注: 6. 4. 4. 1 中归纳和演绎分析的量化估计有助于确定是否需要采取进一步的安全措施,并进行硬件分析,做出最终决定,见 GB / T34590. 5 — 2022 。

6. 4. 5. 3 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在要素层面进行定义,以符合:
a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;
b ) GB / T34590. 5 — 2022 第 9 章中的流程。

6. 4. 5. 4 本要求适用于 ASIL ( B )、 C 和 D 等级。对于分布式开发(见 GB / T34590. 8 — 2022 第 5 章),推导出的目标值应通报给每个相关团队。
注: GB / T34590. 5 — 2022 第 8 章和第 9 章中描述的架构约束,不一定适用于商业现成产品的元器件和组件。这是因为供应商通常不能预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下,供应商会提供基本的数据,例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等,以便允许在整体硬件架构层面上预估架构约束。

6. 4. 6 分配到硬件和软件

6. 4. 6. 1 技术安全要求应分配给以系统、硬件或软件作为实施技术的系统架构设计要素。
注:如果将技术安全要求分配给作为实施技术的系统中,则再次按照 GB / T34590. 4 — 2022 进一步开发这些要求,直到能将他们分配给硬件和软件为止。

6. 4. 6. 2 分配和分区决策应符合系统架构设计。
注:为了实现独立性和避免失效传播,系统架构设计可以采用功能分区和组件分区。

6. 4. 6. 3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

6. 4. 6. 5 如果技术安全要求分配到具备可编程功能的定制化硬件要素[如专用集成芯片( ASIC )、可编程门阵列(FPGA )或是其他形式的数字化硬件],宜结合 GB / T34590. 5 — 2022 和 GB / T34590. 6 — 2022 的要求来定义和实施适当的开发流程。
注 1 :如果满足 GB / T34590. 8 — 2022 第 13 章的应用准则,则可以按照该章的评估方法提供证据证明上述硬件要素中的一些要素满足所分配的安全要求。
注 2 : GB / T34590. 11 — 2022 提供了相应指导。

6. 5. 3 系统架构设计规范,由 6. 4. 3~6. 4. 6 的要求得出。

6. 4. 3 系统架构设计规范和技术安全概念

6. 4. 3. 1 技术安全概念和该子阶段的系统架构设计应基于相关项定义,功能安全概念和先前的系统架构设计。

6. 4. 3. 3 系统架构设计应实现技术安全要求。

6. 4. 3. 5 应定义安全相关要素的内部和外部接口,其他要素不应对安全相关要素产生不利的安全相关影响。

6. 4. 3. 6 如果在系统架构设计期间对安全要求进行 ASIL 等级分解,应按照 GB / T34590. 9 — 2022 第 5 章进行。

6. 4. 4 安全分析及避免系统性失效

6. 4. 4. 2 为符合安全目标或要求,应消除已识别出的引起失效的内部原因,或在必要时减轻它们的影响。

6. 4. 4. 3 为符合安全目标或要求,应消除已识别出的引起失效的外部原因,或在必要时减轻它们的影响。

6. 4. 4. 5 应对值得信赖的设计原则的适用性进行分析并形成文档,以确保其和最终产品应用的一致性和适用性。

6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5. 1 应按照 6. 4. 3 中的系统架构设计,定义探测、控制或减轻随机硬件失效的措施。
示例 1 :这些措施可能是硬件的诊断特性,通过软件对其的使用来探测随机硬件失效。
示例 2 :随机硬件失效发生时,不需要探测即可进入安全状态的硬件设计(即:失效 - 安全的硬件设计)。
注: 6. 4. 4. 1 中归纳和演绎分析的量化估计有助于确定是否需要采取进一步的安全措施,并进行硬件分析,做出最终决定,见 GB / T34590. 5 — 2022 。

6. 4. 5. 4 本要求适用于 ASIL ( B )、 C 和 D 等级。对于分布式开发(见 GB / T34590. 8 — 2022 第 5 章),推导出的目标值应通报给每个相关团队。
注: GB / T34590. 5 — 2022 第 8 章和第 9 章中描述的架构约束,不一定适用于商业现成产品的元器件和组件。这是因为供应商通常不能预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下,供应商会提供基本的数据,例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等,以便允许在整体硬件架构层面上预估架构约束。

6. 4. 6 分配到硬件和软件

6. 4. 6. 1 技术安全要求应分配给以系统、硬件或软件作为实施技术的系统架构设计要素。
注:如果将技术安全要求分配给作为实施技术的系统中,则再次按照 GB / T34590. 4 — 2022 进一步开发这些要求,直到能将他们分配给硬件和软件为止。

6. 4. 6. 2 分配和分区决策应符合系统架构设计。
注:为了实现独立性和避免失效传播,系统架构设计可以采用功能分区和组件分区。

6. 4. 6. 3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

6. 4. 6. 5 如果技术安全要求分配到具备可编程功能的定制化硬件要素[如专用集成芯片( ASIC )、可编程门阵列(FPGA )或是其他形式的数字化硬件],宜结合 GB / T34590. 5 — 2022 和 GB / T34590. 6 — 2022 的要求来定义和实施适当的开发流程。
注 1 :如果满足 GB / T34590. 8 — 2022 第 13 章的应用准则,则可以按照该章的评估方法提供证据证明上述硬件要素中的一些要素满足所分配的安全要求。
注 2 : GB / T34590. 11 — 2022 提供了相应指导。

6. 5. 4 软硬件接口( HSI )规范,由 6. 4. 7 的要求得出。

6. 4. 7 软硬件接口( HSI )规范

6. 4. 7. 1 软硬件接口规范应定义硬件和软件的交互,并保持与技术安全概念一致。软硬件接口规范应包括组件中由软件控制的硬件元器件以及支持软件运行的硬件资源。
注:软硬件接口( HSI )中详细描述的方面和特性见附录 B 。

6. 4. 7. 2 软硬件接口规范应包含下列特性:
a ) 硬件设备的相关运行模式和相关配置参数;
示例 1 :硬件设备的运行模式,例如:默认模式、初始化模式、测试模式或者高级模式。
示例 2 :配置参数,例如:增益控制、带通频率或时钟分频。
b ) 确保要素间独立性或支持软件分区的硬件特征;
c ) 硬件资源的共用和专用;
示例 3 :内存映射、寄存器分配、计时器、中断、 I / O 端口。
d ) 硬件设备的访问机制;
示例 4 :串、并、从、主/从。
e ) 由技术安全概念得出的时间约束。

6. 4. 7. 3 硬件的相关诊断能力和软件对其的使用应在软硬件接口规范中定义:
a ) 应定义硬件的诊断特性;
示例:过流、短路或过温的探测。
b ) 应定义需要在软件中实现的对硬件的诊断特性。

6. 4. 7. 4 应在系统架构设计过程中对软硬件接口( HSI )进行定义。
注:在硬件开发(见 GB / T34590. 5 — 2022 第 6 章)和软件开发(见 GB / T34590. 6 — 2022 第 6 章)过程中对软硬件接口( HSI )进行细化。

6. 5. 5 生产、运行、服务和报废需求规范,由 6. 4. 8 的要求得出。

6. 4. 8 生产、运行、服务和报废

6. 4. 8. 1 应定义在系统架构设计过程中识别出的 GB / T34590. 7 — 2022 中对生产、运行、服务和报废的要求。这些包括:
a ) 在生产、服务或报废期间达到、保持或修复相关项及其要素的安全相关功能和特性所需的措施;
b ) 安全相关的特殊特性;
c ) 确保正确识别系统或要素的要求;
d ) 生产的验证措施;
e ) 包含诊断数据及服务记录的服务要求;
f ) 报废措施。
示例:组装或拆卸指南、服务记录、关于系统要素允许维修的指南、报废指南、要素标签。
注:确保生产、运行、服务和报废期间的功能安全主要包含两方面。第一个方面涉及那些在开发阶段中确保充分的系统架构设计和对合适的安全相关的特殊特性的定义而开展的活动,这些活动在要求 6. 4. 8. 1 中给出,第二方面涉及确保在生产和运行阶段实现或维持功能安全的活动(例如:基于特定的与安全相关的特殊特性),这些活动在 GB / T34590. 7 — 2022 中进行了阐述。

6. 4. 8. 2 在考虑了安全分析的结果和所实施的安全机制的情况下,应定义需具备的诊断特性,以提供按照 GB / T34590. 2 — 2022 第 7 章对相关项或其要素进行现场监控所需的数据。

6. 4. 8. 3 为了修复或保持功能安全,应定义诊断特性以便服务时能够识别故障并对维护或修复的有效性进行检查。

6. 5. 6 针对系统架构设计、软硬件接口规范、生产、运行、服务和报废需求规范及技术安全概念的验证报告,由 6. 4. 9 的要求得出。

6. 4. 9 验证

6. 4. 9. 1 应按照 GB / T34590. 8 — 2022 第 6 章和第 9 章对技术安全要求进行验证,以提供其在给定系统边界条件下的正确性、完整性和一致性的证据。

6. 4. 9. 2 应使用表 2 所列的验证方法对系统架构设计,软硬件接口规范以及生产、运行、服务和报废的要求规范以及技术安全概念进行验证,以提供证据表明实现以下目标:
a ) 它们适合并足以达到按照相关 ASIL 等级所要求的功能安全水平;
b ) 系统架构设计与技术安全概念的一致性;
c ) 先前开发步骤中系统架构设计的有效性和符合性。
注:识别出的安全异常和不完备性按照 GB / T34590. 2 — 2022 中的 5. 4. 3 进行报告。

6. 5. 7 安全分析报告,由 6. 4. 4 的要求得出。

6. 4. 4 安全分析及避免系统性失效

6. 4. 4. 2 为符合安全目标或要求,应消除已识别出的引起失效的内部原因,或在必要时减轻它们的影响。

6. 4. 4. 3 为符合安全目标或要求,应消除已识别出的引起失效的外部原因,或在必要时减轻它们的影响。

6. 4. 4. 5 应对值得信赖的设计原则的适用性进行分析并形成文档,以确保其和最终产品应用的一致性和适用性。

7 系统及相关项的集成和测试工作成果

7. 5. 1 集成和测试策略,由 7. 4. 1 的要求得出。

7. 4. 1 集成和测试策略规范

7. 4. 1. 1 为了提供证据证明系统架构设计符合功能安全和技术安全要求,应按照 GB / T34590. 8 — 2022 第 9 章进行集成测试活动,以检查:
a ) 功能安全及技术安全要求的正确实施;
b ) 安全机制正确的功能性能、准确性和时序;
c ) 接口的一致性和正确实施;
d ) 足够的鲁棒性。

7. 4. 1. 2 应考虑系统架构设计规范、功能安全概念和技术安全概念,定义集成和测试策略,其应该述及:
a ) 适合提供功能安全证据的测试目标;
b ) 相关项及该相关项中有助于安全概念的要素的集成和测试。
注:这包括有助于安全概念的其他技术要素。

7. 4. 1. 3 为使相关项集成子阶段能够进行,应根据集成和测试策略执行以下内容:
a ) 应为软硬件集成和测试定义相关项集成和测试策略;
b ) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件验证的未解决问题得到处理;
c ) 相关项集成和测试策略应考虑车辆系统(相关项内部和外部)与环境之间的接口;
d ) 相关项集成和测试策略应考虑被集成的系统或要素是否是作为独立于环境的安全要素(SEooC )进行开发,以及开发期间所做的假设是否需要验证。
注:在软硬件集成层面和相关项层面进行集成与验证的规范,要考虑软硬件之间的接口及其交互。

7. 4. 1. 6 为了恰当地定义集成测试的测试用例,应考虑集成的层面,使用表 3 中所列的恰当的方法组合导出测试用例。

7. 5. 2 集成和测试报告,由 7. 4. 2 、 7. 4. 3 、 7. 4. 4 的要求得出。

7. 4. 2 软硬件集成和测试

7. 4. 2. 1 软硬件集成

7. 4. 2. 1. 1 应对按照 GB / T34590. 5 — 2022 开发的硬件和按照 GB / T34590. 6 — 2022 开发的软件进行集成,并作为表 4 至表 8 中测试活动的对象。

7. 4. 2. 1. 2 应对集成后的硬件和软件进行测试,以符合软硬件接口规范的要求。
注:首选用于生产的硬件和软件。对于特定的测试技术,必要时可以使用修改过的硬件或软件。

7. 4. 2. 2 软硬件测试中的测试目标和测试方法

7. 4. 2. 2. 1 按照 7. 4. 2. 2. 2~7. 4. 2. 2. 6 要求得出的测试目标,应使用对应表中给出的适当的测试方法来实现。
注 1 :这些目标和方法可以帮助在系统架构设计中对系统性故障的探测。
注 2 :基于已实施的功能、功能复杂性或系统的分布特性,如有足够的理由,在其他集成子阶段执行测试也是可行的。

7. 4. 2. 2. 2 技术安全要求的安全相关功能和行为在软硬件层面的正确执行,应使用表 4 中列出的测试方法来提供证据。
注:表 4 和表 9 中的方法 1b 的工作量差异,是由系统层面的故障注入测试所需要的工作量引起的。7. 4. 2. 2. 3 本要求适用于 ASIL ( A )、 B 、 C 和 D 等级。安全机制在软硬件层面的正确功能性能、准确性和时序,应使用表 5 中给出的测试方法进行论证。

7. 4. 2. 2. 3 本要求适用于 ASIL ( A )、 B 、 C 和 D 等级。安全机制在软硬件层面的正确功能性能、准确性和时序,应使用表 5 中给出的测试方法进行论证。

7. 4. 2. 2. 4 本要求适用于 ASIL ( A )、 B 、 C 和 D 等级。外部和内部接口在软硬件层面执行的一致性和正确性,应使用表 6 中给出的测试方法来提供证据。

7. 4. 2. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。对于故障模型,硬件故障探测机制在软硬件层面上的有效性,应使用表 7 中列出的测试方法进行论证。
注:参考的故障模型,见 GB / T34590. 5 — 2022 附录 D 。

7. 4. 2. 2. 6 本要求适用于 ASIL ( A )、( B )、( C )和 D 等级。要素在软硬件层面的鲁棒性水平,应使用表 8 中给出的测试方法进行论证。

7. 4. 3 系统集成和测试

7. 4. 3. 1 系统集成
系统的各个要素应按照系统架构设计进行集成,并按照系统集成测试规范进行测试。
注:测试目的是提供证据证明各个系统要素正确交互、符合技术和功能安全要求,并为没有可能导致违背安全目标的非预期行为提供足够的置信度水平。

7. 4. 3. 2 系统测试中的测试目标和测试方法

7. 4. 3. 2. 1 按照 7. 4. 3. 2. 2~7. 4. 3. 2. 5 得出的测试目标,应使用对应表中给出的适当的测试方法来实现。
注 1 :这些将支持在系统集成和测试过程中对系统性故障的探测。
注 2 :基于系统已实施的功能、功能复杂性或系统的分布特性,如给出足够的理由,在其他集成的子阶段执行测试也是可行的。

7. 4. 3. 2. 2 功能安全和技术安全要求在系统层面的正确执行,应使用表 9 中列出的测试方法来提供证据。

7. 4. 3. 2. 3 本要求适用于 ASIL ( A )、( B )、( C )和 D 等级。安全机制在系统层面的正确功能性能、准确性、系统层面失效模式的覆盖率、时序,应使用表 10 中给出的测试方法进行论证。

7. 4. 3. 2. 4 外部和内部接口在系统层面执行的一致性和正确性,应使用表 11 中列出的测试方法来提供证据。

7. 4. 3. 2. 5 系统层面的鲁棒性水平,应使用表 12 中给出的测试方法进行论证。

7. 4. 4 整车集成和测试

7. 4. 4. 1 整车集成

7. 4. 4. 1. 1 应将相关项集成到整车上,并实施整车集成测试。
注:当制定整车层面集成与验证计划时,可基于充分的子集考虑车辆在典型和极端车辆状况和环境条件下的正确行为(见表 3 )。

7. 4. 4. 1. 2 应对相关项与车内通信网络以及车内供电网络的接口规范进行验证。

7. 4. 4. 2 整车测试期间的测试目标和测试方法

7. 4. 4. 2. 1 由 7. 4. 4. 2. 2~7. 4. 4. 2. 5 的要求得出的测试目标,应使用对应表格中所列出的适当的测试方法来实现。
注 1 :这些将支持在整车集成过程中对系统性故障的探测。
注 2 :基于系统已实施的功能、功能复杂性或分布特性,如有给出足够的理由,在其他集成的子阶段进行测试是可行的。

7. 4. 4. 2. 2 功能安全要求在整车层面的正确地执行,应使用表 13 中给出的测试方法进行论证。

7. 4. 4. 2. 3 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。安全机制在整车层面的正确功能性能、准确性
和时序,应使用表 14 中列出的测试方法进行论证。

7. 4. 4. 2. 4 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。整车层面内部和外部接口实现的一致性和正确性,应使用表 15 中给出的测试方法进行论证。
注:内部接口是相关项之间或系统之间的接口,外部接口是相关项和整车环境的接口。

7. 4. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。整车层面的鲁棒性水平,应使用表 16 中列出的测试方法进行论证。

8 安全确认工作成果

8. 5. 1 包含安全确认环境描述的安全确认规范,由 8. 4. 1 和 8. 4. 2 的要求得出。

8. 4. 1 安全确认的环境

8. 4. 1. 1 应对整车层面的典型环境下所集成的相关项的安全目标进行确认。
注 1 :如果适用,集成的相关项包括:系统、软件、硬件、其他技术要素和外部措施。
注 2 :这对于 T&B 特别重要,因为它们安全确认的对象可能是不同类型的基础车辆。

8. 4. 1. 2 为了定义典型环境,应考虑基于车型和车辆配置的典型车辆。
注:危害分析和风险评估报告(见 GB / T34590. 3 — 2022 中的 6. 5. 1 )可能是选择典型车辆的一个输入。

8. 4. 1. 3 安全目标的确认应考虑运行过程变化对技术特性的影响,该因素已经在危害分析和风险评估中进行考虑。

8. 4. 2 安全确认的规范
应定义安全确认规范,包括:
a ) 待安全确认的相关项配置,包括其标定数据,应满足 GB / T34590. 6 — 2022 中附录 C 的要求;
注:如果对于每个相关项配置的完整安全确认是不可行的,那么可选择合理的子集。
b ) 安全确认流程、测试案例、驾驶操作和接受准则的定义;
c ) 设备和要求的环境条件。

8. 5. 2 安全确认报告,由 8. 4. 3 和 8. 4. 4 的要求得出。

8. 4. 3 安全确认的执行

8. 4. 3. 1 如果使用测试进行安全确认,那么可应用与验证测试(见 GB / T34590. 8 — 2022 中的 9. 4. 2 和 9. 4. 3 )相同的要求。

8. 4. 3. 2 当相关项集成到整车时,应通过评估如下方面对相关项的功能安全实现进行确认,包括:
a ) 可控性;
注 1 :使用运行场景确认可控性,包括预期用途及可预见的误用。
注 2 :安全确认的一个接受准则是对 GB / T34590.3 — 2022 中的 7. 4. 2. 5 定义的安全状态有充分的可控性。
b ) 外部措施的有效性;
c ) 其他技术要素的有效性;
d ) 影响危害分析与风险评估(见 GB / T34590. 3 — 2022 中的 6. 4. 4. 4 )中 ASIL 等级的假设只能在最终车辆上进行检查。
示例:假设一个机械组件能够防止或减轻由电气/电子系统的功能失效造成的潜在危害,那么这个机械组件防止或减轻危害的有效性只能在整车层面进行确认。

8. 4. 3. 3 应基于安全目标、功能安全要求和预期用途,按计划执行整车层面的安全确认,使用:
a ) 针对每个安全目标的安全确认流程和测试用例,包括详细的通过/未通过准则;
b ) 应用范围。可包括例如配置、环境条件、驾驶场景和操作用例等。
注:可创建操作用例,以助于将安全确认集中在整车层面上。

8. 4. 3. 4 应使用以下方法的适当组合:
a ) 已定义了测试流程、测试案例和通过/未通过准则的可重复性测试;
示例 1 :功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟。
b ) 分析;
示例 2 : FMEA 、 FTA 、 ETA 、仿真。
c ) 长期测试,例如车辆驾驶日程安排和受控测试车队;
d ) 实际使用条件下的操作用例、抽测或盲测、专家小组;
e ) 评审。

8. 4. 4 评估
应对安全确认的结果进行评估,以提供证据证明已实施的安全目标实现了相关项的功能安全。

ISO26262-Part 8:
Supporting processes

5 分布式开发的接口工作成果

5. 5. 1 供应商选择报告,由 5. 4. 2. 1 和 5. 4. 2. 2 的要求得出。

5. 4. 2 供应商选择准则

5. 4. 2. 1 供应商选择准则应包含对供应商开发能力的评估,如果适用,也包含按照 GB / T34590 对类似复杂度和 ASIL 等级的相关项和要素的生产能力的评估。
注:供应商选择准则包含:
———供应商质量管理体系的证据;
———供应商以往的表现和质量;
———对供应商功能安全能力(作为投标的一部分)的确认;
———以往按照 GB / T34590. 2 — 2022 中 6. 4. 12 进行的功能安全评估结果;或
———来自整车厂开发、生产、质量和物流部门(因其影响功能安全)的推荐。

5. 4. 2. 2 客户给候选供应商的报价需求( RFQ )应包含:
a ) 符合 GB / T34590 的正式要求;
b ) 供货范围的定义;
注 1 :供货范围规定了需要供应商提供的相关项或要素的功能、特性和边界。
c ) 如果已存在,基于供应商报价对象的安全目标或相关功能安全要求(包含其分配的 ASIL 等级);
注 2 :如果在选择供应商时 ASIL 等级未知,则可以作出保守的假设。
d ) 如果已存在,基于供应商报价对象的要素的失效率目标值和诊断覆盖率目标值 (按照GB / T34590. 4 — 2022 的 6. 4. 5. 3 )。

5. 5. 2 开发接口协议( DIA ),由 5. 4. 3 、 5. 4. 5. 1 和 5. 4. 5. 2 的要求得出。

5. 4. 3 分布式开发的启动和计划

5. 4. 3. 1 客户和供应商应定义开发接口协议,包含以下内容:
a ) 客户和供应商安全经理的任命;
b ) 按照 GB / T34590. 2 — 2022 的 6. 4. 5 进行安全活动的联合裁剪;
c ) 客户需开展的安全生命周期的活动和供应商需开展的安全生命周期的活动;
注 1 :活动的联合计划是需要考虑的,包含按照 GB / T34590. 2 — 2022 给出的功能安全评估和功能安全审核的职责。
d ) 需共享的信息和工作成果,包含分配和评审;
注 2 :这包括对需提供的文档达成一致,以完成客户及供应商的安全档案。
注 3 :交换的信息包含安全相关的特殊特性。
注 4 :对所涉及开发方的活动所必需的工作成果相关部分,可进行识别和交换。
e ) 每项活动分配给每一方的责任;
注 5 :责任可以描述为“负责”“批准”“支持”“通知”“咨询”。
f ) 目标值的沟通或确认[见 5. 4. 2. 2d )],这些目标值由系统层面的目标导出,再分配给相关方,目的是使这些相关方满足单点故障度量及潜伏故障度量的目标值(按照 GB / T34590.5 — 2022对硬件架构度量的评估和因随机硬件失效导致违背安全目标的评估);
g ) 在客户和供应商合作中所需要的接口相关的流程、方法及工具;
注 6 :流程、工具及工具配置的版本和修订可以是相关的。
h ) 哪一方(供应商或者客户)按照 GB / T34590. 4 — 2022 执行安全确认所达成的协议;
注 7 :如果由供应商执行整车集成和确认,对供应商所需的能力和资源达成一致是重要的,因为安全确认工作需要集成后的车辆(见 GB / T34590.4 — 2022 )。
i ) 按照 GB / T34590. 2 — 2022 ,关于由供应商开发的要素或工作成果的功能安全评估活动;
注 8 :这些由供应商开发的要素或工作成果的功能安全评估活动,可能是由供应商本身、客户,或供应商/客户指定的组织或个人来执行。
j ) 供应商关于功能安全评估报告的计划;
注 9 :开发接口协议包含报告的最低限度内容、版本和里程碑节点。
注 10 :附录 B 给出了开发接口协议的一个示例。
k ) 客户与供应商之间达成的允许客户指定审核人员在供应商的场所进行功能安全审核的协议。

5. 4. 3. 2 如果供应商执行危害分析和风险评估,那么危害分析和风险评估应提供给客户进行验证和批准。

5. 4. 3. 3 概念阶段的责任方应按照 GB / T34590. 3 — 2022 制定功能安全概念。

5. 4. 5 分布式开发中的功能安全评估活动

5. 4. 5. 1 对于分配了安全要求的最高 ASIL 等级为 ASIL ( B )、 C 或 D 的要素,在 DIA 中应指定哪个组织按照 GB / T34590. 2 — 2022 对供应商开发的要素或工作成果执行功能安全评估活动。
注 1 :这些由供应商开发的要素或工作成果的功能安全评估活动,可能由供应商本身、客户,或者客户/供应商指定的组织或人员执行。
注 2 :在 DIA 审批过程中,所有这些都需要与客户达成一致。

5. 4. 5. 2 对于分配了安全要求的最高 ASIL 等级为 ASIL ( B )、 C 或 D 的要素,在 DIA 中应规定供应商功能安全评估活动的计划。
注:计划包括报告的最低限度内容和里程碑节点。

5. 5. 3 供应商安全计划,由 5. 4. 3 和 5. 4. 4 的要求得出。

5. 4. 3 分布式开发的启动和计划

5. 4. 3. 2 如果供应商执行危害分析和风险评估,那么危害分析和风险评估应提供给客户进行验证和批准。

5. 4. 3. 3 概念阶段的责任方应按照 GB / T34590. 3 — 2022 制定功能安全概念。

5. 4. 4 分布式开发的执行

5. 4. 4. 1 客户应确保供应商按时收到所需的用于执行开发接口协议中安全活动的信息和数据。

5. 4. 4. 2 供应商应向客户报告可能增加不符合开发接口协议条款的风险的问题。

5. 4. 4. 3 供应商应向客户报告在其责任范围内和其分包商责任范围内的开发活动中发生的安全异常。

5. 4. 4. 4 应分析已识别出的潜在影响供应商交付成果的安全异常,并采取措施予以解决。双方应就谁来执行所需的行动达成协议。

5. 4. 4. 5 供应商应确定客户的安全要求是否可行,以及 6. 4. 1 和 6. 4. 2 的要求是否满足。若不可行/不满足,则客户应重新检查安全要求并做适当的修改,以确保安全要求定义的正确性。

5. 4. 4. 6 供应商应向客户传达其职责范围以外但供应商认为为确保实现功能安全所必要的相关项的要素的安全要求。

5. 4. 4. 7 在导出用于当前开发的安全要求时,按照 GB / T34590. 2 — 2022 的 5. 4. 2. 6 ,双方都应考虑从之前相似开发中所获得的经验。

5. 4. 4. 8 供应商应向客户报告安全计划中制定的各项任务和里程碑节点上所取得的进展。供应商和客户应就报告的内容和提交的日期达成一致。

5. 5. 4 功能安全评估报告,由 5. 4. 5. 3 和 5. 4. 5. 4 的要求得出。

5. 4. 5 分布式开发中的功能安全评估活动

5. 4. 5. 3 对于分配了安全要求的最高 ASIL 等级为 ASIL ( B )、 C 或 D 的要素,供应商应向客户提供功能安全评估报告,包括供应商对所开发的要素是否符合来自客户的安全要求的评估,以及所实施的流程是否满足实现功能安全的准则。

5. 4. 5. 4 对于分配了安全要求的最高 ASIL 等级为 ASIL ( B )、 C 或 D 的要素,应将供应商的功能安全评估活动的结果提供给客户和供应商。

5. 5. 5 供应协议,由 5. 4. 6. 1~5. 4. 6. 4 的要求得出。

5. 4. 6 生产、运行、服务和报废的协议

5. 4.6.1 供应商应向客户提供证据,证明能具备并保持 GB / T 34590.2 — 2022 的第 7 章和 GB / T34590. 7 — 2022 的第 5 章和第 6 章所要求的生产过程能力。
注:关于半导体生产的指南,参照 GB / T34590. 11 — 2022 的 4. 9 。

5. 4. 6. 2 客户和供应商间的供应协议应按照 GB / T34590. 2 — 2022 的 7. 4. 2. 1 明确功能安全责任,并应定义各方的安全活动。
注:关于半导体分布式开发的指南,参照 GB / T34590. 11 — 2022 的 4. 10 。

5. 4. 6. 3 供应协议应规定各方间关于安全相关特殊特性的生产监控记录和从客户退回部件的失效分析结果的访问和交换。
注:这些事项能由质量管理协议充分覆盖。

5. 4. 6. 4 供应协议应规定关于交换安全相关事件和所需分析的及时的沟通渠道。对于现场问题,就按照已建立的现场监控过程对这些事件进行分析。
注:该分析包括类似相关项和潜在受类似事件影响的其他方。

7 配置管理工作成果

配置管理计划,由 7.4. 1~7. 4. 5 的要求得出。

7. 4. 1 应计划配置管理。
注:配置管理计划可以包括职责和资源、工具和存储库、配置项的识别和命名规范、访问权限、基线计划、发布/批准程序。

7. 4. 2 配置管理过程应符合:
a ) 质量管理体系标准的相关要求;
b ) 软件开发的特定要求。
注 1 : ISO / IEC / IEEE12207 中给出了软件开发的软件配置管理的特定要求。
注 2 :配置管理过程可以适应开发的相应阶段。

7. 4. 3 安全计划要求的工作成果及再次生成相关项和要素所需要的工作成果,应按照配置管理策略,生成基线并存放。

7. 4. 4 在整个安全生命周期中,需要被唯一识别和重生成的工作成果、相关项和要素,在配置管理策略中应定义其条件或目的。
示例:作为客户 - 供应商关系里安全活动的一部分,在其交换之前需要创建工作成果、相关项和要素的配置条件或目的。

7. 4. 5 在整个安全生命周期中,应对配置管理进行维护。

8 变更管理工作成果

8. 5. 1 变更管理计划,由 8. 4. 1 的要求得出

8. 4. 1 计划和启动变更管理

8. 4. 1. 2 应在变更管理计划中识别要进行变更管理的工作成果、相关项和要素,这些工作成果、相关项和要素也要满足 7. 4. 3 的要求。

8. 4. 1. 3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表。

8. 4. 1. 4 变更管理流程应包括:
a ) 变更需求,按照 8. 4. 2 ;
b ) 变更需求分析,按照 8. 4. 3 ;
c ) 变更需求的决策和依据,按照 8. 4. 4 ;
d ) 已接受的变更的实施和验证,按照 8. 4. 5 ;
e ) 文档化,按照 8. 4. 5 。
注 1 :变更管理流程可适用于开发过程中的相应阶段。
注 2 :可在一个变更需求中处理多个变更。

8. 5. 2 变更需求,由 8. 4. 2 的要求得出。

8. 4. 2 变更需求

8. 4. 2. 1 应为每个变更需求分配唯一的识别码

8. 4. 2. 2 每个变更需求应至少包含以下信息:
a ) 日期;
b ) 所需变更的理由;
c ) 所需变更的准确描述;
d ) 所需变更基于的配置。

8. 5. 3 影响分析和变更需求计划,由 8. 4. 3 和 8. 4. 4 的要求得出。

8. 4. 3 变更需求分析

8. 4. 3. 1 对于每个变更需求,应针对以下信息,对所涉及的相关项或要素、接口及关联相关项或要素进行影响分析:
a ) 变更需求的类型;
示例:可能的变更类型有解决错误、调整、消除、加强、预防。
b ) 对需更改的工作成果、相关项和要素及受影响的工作成果、相关项和要素进行的识别;
c ) 在分布式开发的情况下,所涉及的相关方的识别及其责任;
d ) 变更对功能安全的潜在影响;
e ) 变更的实现和验证的日程表。

8. 4. 3. 2 对工作成果的每次变更,应重新启动安全生命周期的适用阶段。后续阶段的开展应符合GB / T34590 。

8. 4. 4 变更需求评估

8. 4. 4. 2 对于每个已接受的变更需求,应决定由谁来开展变更及变更的最晚时间。该决定应考虑开展变更时所涉及的接口。

8. 5. 4 变更报告,由 8. 4. 5 的要求得出。

8. 4. 5 变更的实施和记录

8. 4. 5. 1 应按计划实施变更和验证变更。

8. 4. 5. 2 如果变更影响了安全相关功能或特性,则应在发布相关项前,对按照 GB / T34590. 2 — 2022 中 6. 4. 9 和 6. 4. 10 的功能安全评估和适用的认可评审进行更新。

8. 4. 5. 3 变更的记录应包含以下信息:
a ) 按照第 7 章,在合适的层面下,变更的工作成果、相关项和要素的清单,包括配置和版本;
b ) 开展的变更细节;
c ) 变更部署的计划日期。
注 1 :对临时变更需求,明确指出该变更需求的理由和变更持续的时间(如已知)。
注 2 :对被拒绝的变更需求,记录变更需求和拒绝的理由。

9 验证的工作成果

9. 5. 1 验证计划,由 9. 4. 1. 1 和 9. 4. 1. 2 的要求得出。

9. 4. 1. 1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:
a ) 需验证的工作成果内容;
b ) 验证的目的;
c ) 用于验证的方法;
d ) 验证通过和不通过的准则;
e ) 如果适用,验证环境;
注 1 :验证环境可以是测试环境或模拟环境。
f ) 如果适用,用于验证的设备;
示例:测试工具或者测量设备。
g ) 如果适用,用于验证的资源;
h ) 当探测出异常时需采取的行动;
i ) 回归策略。
注 2 :回归策略定义了在相关项或要素变更后如何重复进行验证。验证可以被全部或部分重复,并可包含其他能影响验证结果的相关项或要素。

9. 4. 1. 2 制定验证计划宜考虑以下方面:
a ) 所使用验证方法的充分性;
b ) 需验证的工作成果的复杂性;
c ) 与验证目标材料相关的前期经验;
注:这包括维修历史及在用证明达到的程度。
d ) 所使用技术的成熟度,或使用这些技术的风险。

9. 5. 2 验证规范,由 9. 4. 2. 1~9. 4. 2. 4 的要求得出。

9. 4. 2. 1 验证规范应对用于验证的方法进行细化,并应包含:
a ) 评审或分析的检查清单;或
b ) 模拟场景;或
c ) 测试用例、测试数据和测试目标。

9. 4. 2. 2 对于测试,每条测试用例的定义应包含以下内容:
a ) 唯一的识别;
b ) 需验证的相关工作成果的版本的参考;
c ) 前提条件和配置;
注 1 :如果对工作成果的可能配置(例如,系统变型)进行完整验证是不可行的,可选择一个合理的子集(例如,系统的最小或最大功能性配置)。
d ) 如果适用,环境条件;
注 2 :环境条件与周围物理属性(例如,温度)有关,测试在该环境进行或模拟部分测试。
e ) 输入数据,数据时序及其值;
f ) 期望的表现,包括输出数据、输出值的可接受范围、时间表现和公差表现;
注 3 :当定义期望的表现时,对初始输出数据的定义可能是必要的,以探测变化。
注 4 :为避免重复定义和存储不同测试用例用到的前提条件、配置及环境条件,有必要使用明确的参考。
g ) 确定测试用例通过和不通过的准则。

9. 4. 2. 3 对于测试,应按使用的测试方法对测试用例进行分组,从以下几个方面考虑:
a ) 所需的测试设备或测试环境;
b ) 逻辑和时间的依赖性;
c ) 资源。
示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 2. 4 对于测试,测试用例宜由与待验证的工作成果的完成人不同的人进行评审

9. 5. 3 验证报告,由 9. 4. 3. 1~9. 4. 3. 4 的要求得出。

9. 4. 3. 1 应按照 9. 4. 1 所做的计划及按照 9. 4. 2 所做的规范,执行验证。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

9. 4. 3. 3 对验证结果的评估应包含以下信息:
a ) 所验证工作成果的唯一识别;
b ) 验证计划和验证规范的参考;
c ) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;
d ) 验证结果与期望结果的一致性水平;
e ) 验证通过或不通过的明确的陈述,如果验证不通过,陈述应包含不通过的理由和对所验证工作成果进行修改的建议;
注:按照验证的完成和结束准则[见 9. 4. 1. 1d )]和预期的验证结果,对验证进行评估。
f ) 每个验证步骤未执行的理由。

9. 4. 3. 4 用于验证的测试设备应能提供有效的和可重复的结果,并应按照所采用的质量管理体系进行管控。

10 文档管理工作成果

10. 5. 1 文档管理计划,由 10. 4. 1 和 10. 4. 2 的要求得出。

10. 4. 1 应计划文档管理过程,以获得文档:
a ) 用于在整个生命周期的每个阶段中有效完成各阶段及验证活动;
b ) 用于功能安全的管理;
c ) 作为认可措施的输入。

10. 4. 2 应将对 GB / T34590 中工作成果的识别理解为文档化要求,文档应包含相关要求的结果信息。
注:文档可以是单个文档的形式,该文档包含工作成果的完整信息;也可以是一组文档的形式,这些文档合起来包含工作成果的完整信息。

10. 5. 2 文档指南要求,由 10. 4. 3~10. 4. 6 的要求得出。

10. 4. 3 文档宜是:
a ) 准确的和简明的;
b ) 结构清晰的;
c ) 目标使用者容易理解的;
d ) 可验证的;
e ) 可维护的。

10. 4. 4 整个文档的结构宜考虑内部流程和工作实践。应对文档进行组织以助于搜索相关信息。
示例:文档树。

10. 4. 5 每个工作成果或文档应包含下面的正式要素:
a ) 题目,参照内容的范围;
b ) 作者和批准者;
c ) 文档每个不同修订(版本)的唯一标识;
d ) 变更历史;
注:变更历史包含每次变更的作者姓名、日期和简要描述。
e ) 状态。
示例:“草稿”“已发布”“有效”“废止”。

10. 4. 6 按照第 7 章,应能识别当前适用的文档修订(版本)或信息项。

11 所使用软件工具的置信度工作成果

11. 5. 1 软件工具准则评估报告,由 11. 4. 1~11. 4. 5 的要求得出。

11. 4. 1 一般要求
如果安全生命周期包含使用软件工具用于系统、硬件要素或软件要素的开发,使得 GB / T34590 要求的活动或任务依赖于软件工具的正确功能,与此同时未按照适用的流程步骤对工具的相关输出进行检查或验证,那么该软件工具应符合本章的要求。

11. 4. 2 预先确定的工具置信度水平的有效性或鉴定的有效性
如果对软件工具的置信度水平评估或鉴定的执行,独立于特定安全相关项或要素的开发,那么应在软件工具用于特定安全相关项或要素开发之前,对预先确定的工具置信度水平的有效性或鉴定的有效性进行验证。
注:关于软件工具、置信度水平评估和鉴定的信息的搜集可以是跨组织的活动,这样有助于减少每个开发项目的难度。

11. 4. 3 软件工具与其评估准则或鉴定的一致性
当使用软件工具时,应确保工具的使用、工具定义的环境和功能约束及其一般运行条件,与工具评估准则或鉴定相符合。
示例:使用案例和实施的预防或探测功能异常及其相应的错误输出的措施,与软件工具鉴定报告中记录的版本和配置设置一致。

11. 4. 4 对软件工具使用的计划

11. 4. 4. 1 应计划软件工具的使用,包括制定:
a ) 软件工具的识别码和版本号;
b ) 软件工具的配置;
示例 1 :通过设定编译器开关和 C 源文件中“ #pragma ”声明,定义编译器的配置。
c ) 软件工具的使用案例;
注 1 :在开展安全生命周期活动时,使用案例可以描述用户与软件工具的配合和软件工具功能的应用子集。
注 2 :使用案例可包含对软件工具配置及软件工具执行环境的要求。
d ) 软件工具执行的环境;
示例 2 :执行软件工具所需的资源、基础设施或运行时环境,应用软件工具所需的流程活动或与软件工具输出结果验证相关的后续流程活动。
e ) 当软件工具功能异常并产生相应的错误输出时,会直接违背分配给相关项或要素的全部安全要求的最高 ASIL 等级;
注 3 :可根据特定开发确定最高 ASIL 等级,或可根据软件工具通用的用法确定最高 ASIL 等级。在预先假定ASIL 等级的情况下,对该假设进行验证。
f ) 如需要,基于确定的置信度水平和 ASIL 等级的软件工具的鉴定方法。

11. 4. 4. 2 为确保恰当地评估或使用软件工具,应具备以下信息:
a ) 软件工具的特征、功能和技术属性的描述;
b ) 如果适用,用户手册或其他使用指南;
c ) 工具运行要求的环境描述;
d ) 如果适用,对异常运行条件下期望的软件工具表现的描述;
示例 1 :异常运行条件可以是禁止的编译开关组合、不符合用户手册的环境或不正确的安装。
示例 2 :异常运行条件下期望的表现可以是对输出生成的阻止、用户提示或用户报告。
e ) 如果适用,对已知软件工具功能异常,及恰当的安全保护、避免或应急措施的描述;
示例 3 :针对已知的功能异常、编译器编码优化局限或建模中使用受限制的一组构件的使用指南或应急措施。
示例 4 :安全保护包括通过使用约束防止全部已知的功能异常和问题、探测和报告全部已知的功能异常和问题,也包括提供安全替代技术以开展相应的活动。
f ) 在制定软件工具要求的置信度水平过程中,识别出的对软件工具功能异常和相应错误输出的预防或探测措施。
注:相应错误输出的预防或探测措施可针对软件工具输出中的已知和潜在错误。
示例 5 :冗余软件工具输出的对比、执行的测试、静态分析或评审、软件工具日志文件的分析、具有已知问题的功能的避免。

11. 4. 5 通过分析对软件工具进行评估

11. 4. 5. 1 对软件工具使用的描述应包含下述信息:
a ) 预期的目的;
示例 1 :功能的模拟、源代码的生成、嵌入式软件的测试、安全生命周期的裁剪、 GB / T34590 要求的活动和任务的简单化或自动化。
b ) 输入和期望的输出;
示例 2 :后续开发活动输入所需的数据、源代码、模拟结果,测试结果,或 GB / T34590 的其他工作成果。
c ) 如果适用,使用过程、环境的和功能的约束。
示例 3 :软件工具嵌入到开发过程、不同软件工具使用共享数据及其他使用条件、预防或探测软件工具的功能异常的流程措施。

11. 4. 5. 2 应分析和评估软件工具的预期使用,以确定:
a ) 特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性。这是通过工具影响( TI )等级表示的:
———当有论据表明没有这样的可能性时,应选择 TI1 ;
———在所有其他情况下应选择 TI2 。
b ) 用于预防软件工具功能异常并产生相应错误输出的措施的置信度,或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度。这是通过工具错误探测( TD )等级表示的:
———当对预防或探测出功能异常及其相应错误输出具有高置信度时,应选择 TD1 ;
———当对预防或探测出功能异常及其相应错误输出具有中等置信度时,应选择 TD2 ;
———在所有其他情况下应选择 TD3 。
注 1 :预防或探测可通过流程步骤、任务或软件工具的冗余,或软件工具自身的合理性检查完成。
注 2 :如果具备的开发流程中没有系统性措施,则典型适用 TD3 ,为此,仅能随机探测出软件工具的功能异常及其相应错误输出。
注 3 :如果用一个软件工具验证另一软件工具的输出,当评估这一软件工具时,考虑软件工具间的相互依赖性,为该软件工具选择一个充分的 TD 。例如,工具之间可能因使用了公共组件或者共享资源而存在相互依赖性。
注 4 :此使用分析的详细程度仅需要允许恰当地确定 TI 和 TD 的等级。
示例 1 :在按照 GB / T34590 对产生的源代码进行验证的情况下,为代码生成器选择 TD1 。当不对产生的源代码进行验证时,为代码生成器选择 TD3 。
示例 2 :使用指南防止功能异常,例如,编译器对代码构成的错误或不清晰的理解。
示例 3 :针对用于静态验证源代码中不存在潜在的除零情况的工具,如果为此目的也同时进行了测试,则可为该工具选择 TD2 。如果仅通过工具验证不存在除零的情况,可为该工具选择 TD3 。

11. 4. 5. 3 如果对 TI 或 TD 选择的正确性是不清楚的或可疑的,宜对 TI 和 TD 进行保守评估。

11. 4. 5. 4 基于为 TI 和 TD 等级确定的值(按照 11. 4. 5. 2 或 11. 4. 5. 3 ),应按照表 3 来确定所要求的软件工具的置信度水平。

11. 5. 2 软件工具鉴定报告,由 11. 4. 6~11. 4. 9 的要求得出。

11. 4. 6 软件工具的鉴定

11. 4. 6. 1 对鉴定等级为 TCL3 的软件工具,应使用表 4 列出的方法。对鉴定等级为 TCL2 的软件工具,应使用表 5 列出的方法。等级为 TCL1 的软件工具无需鉴定方法。

11. 4. 6. 2 应对软件工具的鉴定进行文档化,包含以下信息:
a ) 软件工具的唯一识别码和版本号;
b ) 软件工具划分的最高工具置信度等级,及其评估分析参考;
c ) 对于考虑的使用案例,当软件工具功能异常并产生相应的错误输出时,可能直接违背任何安全要求的预定义最高 ASIL 等级或特定 ASIL 等级;
d ) 软件工具被鉴定的配置和环境;
e ) 执行鉴定的人员或组织;
f ) 鉴定使用的方法,按照 11. 4. 6. 1 ;
g ) 用于鉴定软件工具的措施结果;
h ) 如果适用,在鉴定过程中识别出的使用约束和功能异常。

11. 4. 7 使用中积累置信度

11. 4. 7. 1 如果按照表 4 或表 5 ,将“使用中积累置信度”的方法用于软件工具的鉴定,则应满足此条的要求。

11. 4. 7. 2 仅当具备以下方面的证据时,才应论证软件工具在使用中积累了置信度:
注 1 :第 14 章中在用证明的要求不适用于本条。
a ) 此前,已经将该软件工具用于相同的目的,具有相似的使用案例、相似的预定运行环境和相似的功能约束中;
b ) 使用中积累置信度的理由是基于充分适当的数据;
注 2 :可从累计使用量中获得数据(例如,时间长度或频率)。
c ) 软件工具的定义未改变;
d ) 在之前开发中获得的软件工具功能异常和相应错误输出的发生案例是以系统化方式累计的。

11. 4. 7. 3 应通过考虑以下信息,对给定开发活动中软件工具的先前使用经验进行分析和评估:
a ) 软件工具唯一的识别码和版本号;
b ) 软件工具的配置;
c ) 使用周期和使用相关数据的细节;
示例 1 :软件工具相关使用案例中,使用的软件工具特征及使用频率。
d ) 软件工具的功能异常和相应错误输出的详细文档化记录,其中包含引起功能异常和错误输出的条件;
e ) 所监控的先前版本清单,其中列出每个相关版本中解决的功能异常;
f ) 如果适用,对已知缺陷的安全保护、避免措施、应急措施或相应错误输出的探测措施。
示例 2 :使用报告的来源可以是日志、供应商提供的软件工具版本历史、已发布的勘误表。

11. 4. 7. 4 使用中积累置信度的论证应仅对所评估的软件工具版本有效。

11. 4. 8 工具开发流程评估

11. 4. 8. 1 如果按照表 4 或表 5 ,将“工具开发流程评估”的方法用于软件工具的鉴定,则应满足此条的要求。

11. 4. 8. 2 用于软件工具开发的流程应满足适当的标准。
注:对于开源开发,那些团体使用的某些标准也可能是适当的。

11. 4. 8. 3 应基于恰当的国内或国际标准对软件工具开发流程进行评估,同时提供恰当的软件开发流程被应用的证据。
注:该评估涵盖了对软件工具的一个恰当且相关的特征子集的开发。
示例:使用基于 AutomotiveSPICE􀇀 、 ISO / IEC33000 或 CMMI 的评估方法。

11. 4. 9 软件工具确认

11. 4. 9. 1 如果按照表 4 或表 5 ,将“软件工具确认”的方法用于软件工具的鉴定,则应满足此条的要求。

11. 4. 9. 2 软件工具的确认应满足以下准则:
a ) 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;
注 1 :确认提供了评估的工具错误不会发生或将被检测到的证据。
注 2 :确认可通过使用用户开发的或工具供应商(如果供应商的测试套件包括用户的工具使用案例)开发的自定义测试套件来实施。
示例 1 :编程语言标准有助于定义相关编译器的确认要求。
b ) 应对确认中发生的软件工具功能异常及其相应错误输出、其可能的后果信息以及避免或探测它们的措施进行分析;
c ) 应检查软件工具对异常运行条件的响应。
示例 2 :可预见的误用、不完整的输入数据、不完整的软件工具升级、使用被禁止的配置设置组合。

12 软件组件的鉴定工作成果

12. 5. 1 软件组件的文档,由 12. 4. 2. 1 的要求得出。

12. 4. 2. 1 软件组件鉴定的定义应包括:
a ) 软件组件的唯一识别;
b ) 当软件组件错误执行时,可能违背的所有安全要求的最高 ASIL 等级;
c ) 为鉴定软件组件所应执行的活动;
d ) 软件组件的要求;
示例 1 :要求可包括:
———功能要求;
———已知的安全要求;
———算法精度或数值精度,算法精度考虑仅提供近似解的程序误差,数值精度考虑由计算误差导致的取整误差,以及在电控单元中函数的近似表达所引起的截断误差;
———失效情况下的表现;
———响应时间;
———资源使用;
———运行环境的要求;
———过载情况下的表现(鲁棒性)。
e ) 软件组件预期用途的要求;
f ) 配置描述;
注 1 :对于包含多个软件单元的软件组件,配置描述包括每个软件单元的唯一识别和配置。
g ) 如有,所需接口的描述、供给接口的描述、共享资源的描述;
h ) 应用手册(在适当的情况下);
i ) 正确集成与使用软件组件所需的开发工具;
注 2 :描述包括正确集成与使用软件组件所需的开发工具的配置参数。
j ) 异常运行条件下,所执行的功能的反应;
示例 2 :对非重入软件功能的重入调用的反应。
k ) 对已知异常及相应应急措施的描述。

12. 5. 2 软件组件鉴定报告,由 12. 4. 2. 2~12. 4. 2. 5 的要求得出。

12. 4. 2. 2 为提供证据表明软件组件符合其要求,软件组件的验证应:
a ) 展示对要求的覆盖率,按照 GB / T34590. 6 — 2022 的第 9 章;
注:该验证是主要基于要求的测试,可使用软件组件开发过程中或在之前的集成测试中执行的基于要求的测试结果。
示例:专用鉴定测试套件的应用,对软件组件实施和全部集成期间的所有已执行测试的分析。
b ) 既覆盖正常运行条件,也覆盖失效情况下的表现;
c ) 显示可能会导致违背分配给该软件组件安全要求的非已知错误。

12. 4. 2. 3 本要求适用于 ASILD ,按照 4. 4 :结构覆盖率应按照 GB / T34590. 6 — 2022 的第 9 章来测量,以评估测试用例的完整性。

12. 4. 2. 4 按照 12. 4. 2. 2 的验证,应仅对软件组件未经改变的实现有效。

12. 4. 2. 5 应对软件组件的鉴定进行记录,包括下述信息:
a ) 软件组件的唯一识别;
b ) 软件组件的唯一配置;
c ) 执行鉴定的人员或组织;
d ) 用于鉴定的环境;
e ) 用于鉴定软件组件的验证措施的结果;
f ) 分配给软件组件的安全要求的最高 ASIL 等级。

12. 5. 3 软件组件鉴定的验证报告,由 12. 4. 3 的要求得出。

12. 4. 3 软件组件鉴定的验证
应按照第 9 章验证软件组件的鉴定结果连同这些结果对软件组件预期使用的有效性。

13 硬件要素评估工作产品

13. 5. 1 硬件要素评估计划,由 13. 4. 3. 2 的要求得出。

13. 4. 3. 2 评估计划
应开发评估计划,并应描述:
a ) 硬件要素的唯一识别及版本;
b ) 硬件要素预期使用环境的定义;
c ) 评估策略和依据;
注:策略包括分析、必要的测试和逐步的描述。
d ) 该策略所必需的工具和设备;
e ) 实施该评估的责任方;
f ) 用于评估硬件要素通过和不通过的准则。

13. 5. 2 如果适用,硬件要素测试计划,由 13. 4. 3. 5. 1 的要求得出。

13. 4. 3. 5. 1 应制定测试计划,且测试计划应包含下列信息:
a ) 硬件要素的功能描述;
b ) 所分配的安全要求;
c ) 需要进行的测试规范和顺序;
d ) 测试与安全要求之间的追溯性;
e ) 组装和连接的要求;
f ) 需要模拟的运行条件和环境条件;
g ) 被测要素的数量;
h ) 测试通过/不通过的准则;
i ) 需要测量的环境参数;
j ) 对测试设备的要求,包括精度。

13. 5. 3 如果适用,硬件要素评估报告,由 13. 4. 1. 1 、 13. 4. 3. 6 和 13. 4. 4. 3 的要求得出。

13. 4. 1. 1 被评估硬件要素的分类
硬件要素应被分为以下类别之一:
a ) Ⅰ 类要素,如果:
———该要素最多有几种状态,且这几种状态可以从安全的视角被充分地表征、测试和分析;
———可以在不了解该要素的实现细节和生产过程的情况下,识别并评估该要素的安全相关的失效模式;
———该要素没有与安全概念相关的控制或探测其内部失效的内部安全机制。
注 1 :这并不包含监控要素外部特性的安全机制。
示例 1 :电阻、电容、晶体管、二极管、晶振、谐振器。
b ) Ⅱ 类要素,如果:
———具有例如较少运行模式、较小取值范围、较少参数的要素,并且可以在不了解实现细节的情况下从安全的角度对其进行分析;
———现有的文档可以提供有效的假设,以支持通过测试和分析评估系统性故障,而无需了解该要素的实现细节和生产过程;
示例 2 :数据表、用户手册、应用说明。
———该要素没有与安全概念相关的控制或探测其内部失效的内部安全机制。
注 2 :这并不包含监控要素外部特性的安全机制。
示例 3 :燃油压力传感器、温度传感器、没有与安全概念相关的内部安全机制的独立模数转换器( ADC )。
c ) Ⅲ 类要素,如果:
———具有例如较多运行模式、较大取值范围、较多参数的要素,并且在不了解实现细节的情况下,不能进行分析;
———系统性故障的来源只能通过实现细节、开发过程和/或生产过程的方式来理解和分析;或
———该要素具有与安全概念相关的控制或探测其内部失效的内部安全机制。
示例 4 :微处理器、微控制器、数字信号处理器( DSP )。

13. 4. 3. 6 评估报告

13. 4. 3. 6. 2 应按照第 9 章对评估报告进行验证。

14 在用证明工作产品

14. 5. 1 用于在用证明的候选项描述,由 14. 4. 3 的要求得出。

14. 4. 3 候选项的最低限度信息
应具备对候选项及其之前使用的描述,以及包括:
a ) 如有,候选项的识别和追溯,以及内部要素或组件的目录;
b ) 相应的配合要求、形式要求和功能要求,若适用,并描述候选项的接口和环境特性、物理和尺寸特性、功能和性能特性;
c ) 如果适用,候选项之前使用时的安全要求以及相应的 ASIL 等级。

14. 5. 2 在用证明分析报告,由 14. 4. 4~14. 4. 5 的要求得出。

14. 4. 4 候选项修改分析

14. 4. 4. 1 在用证明的候选项
应按照 14.4. 4. 2~14. 4. 4. 3 识别出对候选项以及其环境的修改。
注 1 :候选项的修改是指设计变更和实施变更。要求更改、功能性加强或性能加强可导致设计变更。实施变更不影响候选项的定义或其性能,仅影响其实施特性。软件更正、使用新的开发工具或生产工具可导致实施变更。
注 2 :配置数据或标定数据的更改如果影响了候选项的表现并与违背安全目标相关,则认为这些更改是对候选项的修改。
注 3 :将候选项用于具有不同安全目标或要求的新型应用、将候选项安装于新的目标环境(如车辆变型、环境条件范围)、与候选项存在相互作用的组件升级或位于候选项附近的组件升级都可导致候选项环境的变更。

14. 4. 4. 2 为未来应用引入的相关项修改
以未来应用为目的而引入的相关项及其环境的修改,应符合 GB / T34590.2 — 2022 的 6. 4. 3 。

14. 4. 4. 3 为未来应用引入的要素修改
以未来在不同相关项中进行应用为目的而引入的要素及其环境的修改,应符合 GB / T34590.2 —2022 的 6. 4. 4 。

14. 4. 4. 4 独立于未来应用的候选项修改
在候选项评估期后引入的、独立于未来应用的候选项修改,应提供在用证明状态仍然有效的证据。

14. 4. 5 现场数据的分析

14. 4. 5. 1 配置管理和变更管理
应提供候选项在其服务期内及评估期结束后处于配置管理和变更管理管辖下的证据,以便于建立候选项的当前状态。

14. 4. 5. 2 在用证明的目标值
注:如果还没有分配任何 ASIL 等级给候选项,可保守的选取 ASILD 等级。

14. 4. 5. 2. 1 应具备候选项评估期的计算依据。

14. 4. 5. 2. 2 候选项的评估期应按照 14. 4. 5. 2. 3 ,由所参考全部样本的观察期的累加得出。

14. 4. 5. 2. 3 对每个与候选项具有相同定义和实现,并在车辆上运行的样本的观察期,应超过年平均车辆运行时间,才能在候选项评估期的分析中考虑。

14. 4. 5. 2. 4 为了使候选项达到在用证明状态,候选项应在评估期内证明对每个可能被候选项违背的安全目标的符合性,符合表 6 ,且具备单侧置信下线为 70% (使用卡方分布)。
注 1 :为了在用证明的目的,可观察到的事件意味着报告给制造商的失效和由候选项导致的潜在违背安全目标的失效。
注 2 :在分析现场安全目标的潜在违背时,解释了可观察到的事故的特征和发生率。
注 3 :表 7 给出了无可观察到的事故的最短评估周期的示例,这是达到 70% 置信度所必需的。
注 4 :如果在样本的采集数据中发现可观察到的事件,必需的最短评估期 t service 可进行如下调整:
t service = t MTTF ×(Xcl , 2 f +2 )^2/2
CL———置信度的绝对值(例如,0. 7 对应了 70% );
t MTTF———平均失效间隔(1 /失效率);
f———安全相关事件的数量;
( χ α ,υ )2 ———误差概率 α 和自由度 υ 的卡方分布。

14. 4. 5. 2. 5 在获得在用证明状态(按照 14. 4. 5. 2. 4 )前,可暂时预计所用的在用证明可信度。在这种情况下,对每个可能被候选项违背的安全目标,候选项评估期应证明对其符合性,并应满足表 8 且具备单边置信下限为 70% (使用卡方分布)。

14. 4. 5. 2. 6 在 14. 4. 5. 2. 5 描述的临时期内,对任何现场观察到的事件,应遵循以下方面:
———对可观察到的事件率停止使用表 8 ,而对候选项使用表 6 ,或反之;
———提供证据证明已完全识别出观察到的事件的根本原因并按照 GB / T34590 进行了排除,同时,继续对候选项累计小时进行计数,重置该特定根本原因的累计小时计数,并将这条证据记录到安全档案中。

14. 4. 5. 2. 7 当候选项的失效率是非恒定值时,在用证明应采用额外的措施,例如,因疲劳导致损坏的情况。
注:这些措施适用于其失效率显著依赖于某些因素(诸如与相关项生命周期相关的磨损、老化或运行时间)的候选项。措施可包括专用的耐久测试,或更长的观察期。

14. 4. 5. 3 现场问题
问题报告系统应确保获取并记录了候选项运行期间,现场中任何由候选项引起的、具有潜在安全影响的可观察到的事件(见 GB / T34590.2 — 2022 的 7. 4. 2. 3 )。

15 GB / T34590 适用范围之外应用的接口工作产品

基础车辆制造商或供应商指南,由 15. 4. 2 和 15. 4. 3 的要求得出。

15. 4. 2 基础车辆制造商、相关项或要素的供应商应向集成方沟通信息,识别可修改的系统和组件以及允许的系统安全限制/修改的要求。

15. 4. 3 基础车辆制造商或相关项的供应商应针对要求集成方采取的安全措施进行沟通。
注 1 :假设集成方具备实现安全措施的必要能力。
示例 1 :集成方的能力准则可以是:
———符合其他安全标准;
———适当的安全文化;
———已建立的质量管理体系。
注 2 :基础车辆制造商、相关项或要素的供应商对预期的集成用例及其安全要求做出假设。如有例外情况,集成方针对安全要求与基础车辆制造商、相关项或要素的供应商进行沟通。
示例 2 :在驾驶过程中,车身制造商联系基础车辆制造商请求开启 PTO 功能。车身制造商使用 ISO13849 开发,双方针对在 ISO13849 基础上增加的 ASIL 等级达成一致。基础车辆制造商沟通关于 PTO 功能相关的带有 ASIL 等级的安全要求,车身制造商(以商定的性能等级)符合这些要求。基础车辆制造商启用车身制造商所请求的 PTO 功能。

16 未按照 GB / T34590 开发的安全相关系统的集成工作产品

安全依据,由 16. 4. 2~16. 4. 4 的要求得出

16. 4. 2 在集成方安全档案中应给出依据,以证明本章应用的合理性。
示例:供应商遵循安全标准 ISO13849

16. 4. 3 集成方应定义准则,以论证按照另一安全标准开发的安全相关系统符合所需的功能安全要求的等级。
示例 1 : ASIL 等级和 PL 等级( ISO13849 中使用的性能等级)之间的映射。
注:该准则涉及设计流程、产品设计、认证措施和审批流程。
示例 2 :不同安全标准之间,对于应用方法要求和所需失效率要求的对比。

16. 4. 4 集成方和供应商应就相关的一系列措施达成一致,以验证是否满足准则。
示例:一系列措施可以是:
———待集成系统规范的可用性;
———通过测试报告证明待集成系统符合其要求的证据;
———通过 FMEA 、 FTA 、既定设计模式/配置的应用,对系统性设计故障进行结构化设计分析;
———待集成系统适合其预期用途的证据;
———基于充分的 PPAP (生产件批准程序)审批流程,对组件进行产品发布的证据;
———通过高加速寿命测试、环境测试、超出规范限制的测试、鲁棒性测试进行的设计验证与设计确认测试;
———现场数据分析。

ISO26262-Part2
Management of functional safety

5 整体安全管理工作成果

5. 5. 1 组织的专门的功能安全规章和流程,由 5. 4. 2~5. 4. 6 得出。

5. 4. 2 安全文化

5. 4. 2. 1 组织应创造、培育并保持一种安全文化,以支持并鼓励有效地实现功能安全。
注:附录 B 提供了构建安全文化的更多细节。

5. 4. 2. 2 组织应建立、执行并维护组织的专门的规章和流程,以实现且维护功能安全并符合 GB / T34590的要求。
注:组织的专门的规章和流程可包括创建并维护通用的计划(例如,通用安全计划)或通用的流程描述。

5. 4. 2. 3 组织应建立并维护功能安全、信息安全及与实现功能安全相关的其他领域之间的有效沟通渠道。
示例 1 :建立功能安全和预期功能安全之间的沟通渠道。
示例 2 :建立功能安全与信息安全之间的沟通渠道,以便于两者交互相关信息(例如,在识别到信息安全问题可能违背安全目标或安全要求的情况下,或在信息安全要求可能与功能安全要求冲突的情况下)。
示例 3 :建立功能安全和非电气/电子系统相关安全(如机械安全)之间的沟通渠道。
示例 4 :建立功能安全和质量之间的沟通渠道。
注:关于功能安全与信息安全潜在交互的指导见附录 C 。

5. 4. 2. 4 在安全生命周期执行期间,组织应执行要求的安全活动,包括文档的创建和管理(按照GB / T34590. 8 — 2022 中第 10 章的规定)。

5. 4. 2. 5 组织应为功能安全的实现提供所需的资源。
注:资源包括人力资源、工具、数据库、指南和工作说明。

5. 4. 2. 6 基于以下几点,组织应建立、执行并维护持续改进的流程:
———从其他相关项安全生命周期的执行过程中学习经验,包括现场经验;
———将获得的改进应用于后续相关项。

5. 4. 2. 7 组织应确保给予负责实现或维护功能安全、执行或支持安全活动的人员以足够的权限来履行
他们的职责。

5. 4. 3 关于功能安全的安全异常管理

5. 4. 3. 1 组织应建立、执行并维护流程,以确保将识别出的安全异常明确传达给负责在安全生命周期内实现或维护功能安全的人员。
注:根据安全异常情况,责任人可包括客户安全经理、供应商安全经理、与相关项开发相关的安全经理,或在生产、运行、服务和报废期间实现和维护功能安全的人员。

5. 4. 3. 2 组织应建立、执行和维护安全异常解决流程,以确保及时、有效地分析、评估、解决和管理已识别的安全异常,直至关闭。
注 1 :安全异常的解决流程可包括根本原因分析,由该根本原因分析得出对以后的修正行动。
注 2 :如果安全异常的解决导致变更,则按照 GB / T34590.8 — 2022 的第 8 章,将该变更纳入变更管理流程。
注 3 :安全经理可以提名负责解决安全异常的人员。
注 4 :安全异常解决流程可以整合进质量管理体系的异常解决流程中(见 5.4. 5 )。

5. 4. 3. 3 只有达成以下条件,安全异常才应认为被关闭:
a ) 基于某一依据,实施了充分的安全措施以解决安全异常,且安全措施的有效性得到了验证;或
注 1 :在设计变更解决了安全异常的情况下,按照 GB / T34590.8 — 2022 的第 8 章进行的相应的影响分析可提供依据。
注 2 :安全异常可以通过其他技术实施的措施或外部措施(例如, GB / T34590 范围外的措施)解决。
b ) 基于某一依据,将安全异常评估为不构成不合理风险并将其关闭。
注 3 :如果没有合理依据,则无法关闭安全异常。

5. 4. 3. 4 应对 5. 4. 3. 3 规定的关闭安全异常的依据进行记录,并应进行评审。
示例:对关闭安全异常的依据的评审可以作为功能安全评估的一部分(见 6. 4. 12 )。

5. 4. 3. 5 未完成关闭的安全异常应上报给负责功能安全的人员,比如将涉及产品开发的安全异常上报给项目经理。
注:如果在开发过程中识别到安全异常,但未完成关闭,而此时进行功能安全评估,则负责功能安全评估的人员是需被明确传达安全异常的人员之一。

5. 4. 4 能力管理

组织应确保执行安全生命周期活动的人员具有与其职责相匹配的技能水平、能力和资质。
注 1 :在开发过程中,达到足够的技能水平和能力的方法之一是考虑以下知识领域的培训和资质培养:
———常规的安全实践、概念和设计;
——— GB / T34590 和其他适用的安全标准;
———用于功能安全组织的专门规则;
———用于与功能安全交互专业的组织的专门规则;
———组织所建立的功能安全流程。
注 2 :为了评估执行满足 GB / T34590 的活动所需的技能、能力和资质,可以考量以往的专业活动经验,如:
———相关项专业领域的知识;
———相关项环境方面的专业知识;
———管理经验;
———生产、运行、服务和报废方面的专业知识。
注 3 :组织可以定义技能、能力和资质的充分性的标准。
示例:英国健康与安全执行局在“安全相关系统管理能力”中给出的准则

5. 4. 5 质量管理体系

组织应具有支持实现功能安全并满足质量管理标准如 IATF16949 、ISO9001 或等同标准的质量管理体系。

5. 4. 6 独立于项目的安全生命周期剪裁

在以下情况下,组织可剪裁应用于各相关项或要素的安全生命周期(即独立于项目的剪裁):
a ) 合并或分解子阶段、活动或任务;
注:如果所用的方法难以清晰地区分单独的子阶段,那么这些子阶段可以合并。例如,计算机辅助开发工具能在一个步骤中支持多个子阶段的活动。
b ) 在不同的阶段或子阶段中执行同一活动或任务;
c ) 在新增的阶段或子阶段中执行同一活动或任务;
d ) 反复进行某个阶段或子阶段;
e ) 若符合 6. 4. 7. 1 ,执行与其他阶段或子阶段的安全活动同时进行的安全活动;或
f ) 根据某个理由,省略不适用于组织的阶段或子阶段。

5. 5. 2 能力管理证据,由 5. 4. 4 得出。

5. 4. 4 能力管理

5. 5. 3 质量管理体系证据,由 5. 4. 5 和 5. 4. 6 得出。

5. 4. 5 质量管理体系

组织应具有支持实现功能安全并满足质量管理标准如 IATF16949 、ISO9001 或等同标准的质量管理体系。

5. 4. 6 独立于项目的安全生命周期剪裁

5. 5. 4 已识别的安全异常报告(如果适用),由 5. 4. 3 得出。

5. 4. 3 关于功能安全的安全异常管理

6 项目相关的安全管理工作成果

6. 5. 1 相关项层面的影响分析,由 6. 4. 3 得出。

6. 4. 3 相关项层面的影响分析

6. 4. 3. 1 在安全生命周期开始时,应进行相关项层面的影响分析,以确定相关项是全新开发,或是对现有相关项修改,还是对现有相关项的使用环境进行修改。
注:在用证明可适用于修改的情况(见 GB / T34590.8 — 2022 的第 14 章)。

6. 4. 3. 2 在对相关项或其环境修改的情况下,按照 6. 4. 3. 1 执行的相关项层面的影响分析应识别并描述应用于相关项的修改,包括:
注 1 :本章考虑的影响分析关注计划阶段相关项的修改。在开发执行过程中的设计修改是通过变更管理流程实现的(见 GB / T34590.8 — 2022 的第 8 章)。
注 2 :设计的修改可来自需求的修改。
注 3 :设计的修改可以影响相关项的行为。
示例 1 :设计的修改可来自标定数据的修改。
示例 2 :设计的修改可来自相关项运行模式的更改。
b ) 实现方式的修改;
注 4 :实现方式的修改不影响相关项的规格或性能。
注 5 :对于相关项实现方式的修改,可能会影响相关项的行为。
注 6 :实现方式的修改可来自软件的修正。
c ) 与环境相关的修改。
示例 3 :温度、海拔、湿度、振动、电磁干扰( EMI )和燃料类型。
注 7 :修改包括:
———将相关项安装于新的目标环境(如车辆变型);
———运行场景的变更;
———相关项在车内的不同位置。

6. 4. 3. 3 按照 6. 4. 3. 2 ,相关项层面的影响分析应:
a ) 评估修改对功能安全的影响;
b ) 基于修改的影响,识别并描述要开展的安全活动。

6. 5. 2 要素层面的影响分析,如果适用,由 6. 4. 4 得出。

6. 4. 4 现有要素的复用
在复用现有要素时,应执行要素层面的影响分析,包括:
a ) 识别运行环境的修改,包括其导致的对要素的修改;
b ) 无论复用的要素是否进行修改,都需要评估其能否符合分配给其的安全要求,这些安全要求来自集成该要素的相关项或要素;
注 1 :无论是否计划对现有要素进行修改,它都可以被复用。例如,可以计划对要素进行修改,以实现现有要素的集成。
c ) 基于修改影响(包括先前假设有效性的影响)进行评估,识别要执行的安全活动;
d ) 评估与复用要素有关的现有安全相关文档,并判断其是否支持将要素集成到相关项,或将要素集成到另一个要素。
注 2 :本章中考虑的影响分析涉及在计划阶段考虑的要素运行环境的修改。开发过程中考虑的设计修改通过变更管理流程执行。(见 GB / T34590.8 — 2022 的第 8 章)。
注 3 :现有要素的复用需:
a ) 基于硬件要素的评估(见 GB / T34590. 8 — 2022 的第 13 章);
b ) 基于软件组件的鉴定(见 GB / T34590. 8 — 2022 的第 12 章);
c ) 基于在用证明(见 GB / T34590. 8 — 2022 的第 14 章);或
d ) 作为独立于环境的安全要素(见 GB / T34590. 10 — 2022 )。

6. 5. 3 安全计划,由 6. 4. 5~6. 4. 13 得出。

6. 4. 5 安全活动的剪裁

6. 4. 5. 1 可以对特定相关项开发的安全活动进行剪裁,即省略或以不同于 GB / T34590 所参考的生命周期中规定的方式执行。如果安全活动被剪裁,那么:
a ) 应在安全计划中定义该剪裁[见 6. 4. 6. 5b )];
b ) 应给出理由说明为什么剪裁对于实现功能安全来说是恰当且充分的。
注 1 :该理由考虑相关要求的 ASIL 等级。
注 2 :剪裁的理由包含在安全计划中且在安全计划的认可评审(见 6. 4. 9 )或功能安全评估(见 6. 4. 12 )过程中进行评审。
注 3 :本要求适用于特定相关项的安全活动的剪裁。关于组织层面相关项开发的安全生命周期的剪裁,仅 5. 4. 6适用。

6. 4. 5. 2 如果是按照影响分析结果(按照 6. 4. 3 或 6. 4. 4 )对某一安全活动按照 6. 4. 5. 1 进行剪裁,则应满足 6.4. 6. 7 的要求。

6. 4. 5. 3 如果由于在用证明结果而按照 6.4.5.1 对某一安全活动进行剪裁,则剪裁应满足GB / T34590. 8 — 2022 中第 14 章的要求。

6. 4. 5. 4 如果由于硬件要素评估而按照 6.4.5.1 对某一安全活动进行剪裁,则剪裁应满足GB / T34590. 8 — 2022 中第 13 章的要求。

6. 4. 5. 5 如果是由于软件组件鉴定而按照 6.4.5.1 对某一安全活动进行剪裁,则剪裁应满足GB / T34590. 8 — 2022 中第 12 章的要求。

6. 4. 5. 6 如果基于考虑所使用软件工具的置信度的依据而按照 6. 4. 5. 1 对某一安全活动进行剪裁,则应满足 GB / T34590.8 — 2022 中第 11 章的要求。

6. 4. 5. 7 如果由于要素被开发为独立于环境的安全要素( SEooC )而按照 6. 4. 5. 1 对某一安全活动进行剪裁,那么:
a ) 独立于环境的安全要素的开发应基于一个需求规范,该需求规范来自对预期用途和环境的假设,包括其外部接口;
b ) 当安全要素被集成到其目标应用中时,应验证对独立于环境的安全要素的预期用途和应用环境的假设。
注 1 :本文件作为一个整体不能应用于独立于环境的安全要素的开发,因为功能安全不是一个要素属性(然而一个相关项中的某一个要素可以认为是与安全相关的)。功能安全是一个可以通过功能安全评估方法来评价的相关项的属性。
示例:微控制器作为独立于环境的安全要素开发。
注 2 :了解更多独立于环境的安全要素的开发见 GB / T34590.10 — 2022

6. 4. 5. 8 本要求适用于 T&B 的相关项的开发:如果某个应用超出了 GB / T34590 的范围,且该应用正在与已根据这些标准开发的基础车辆或相关项进行对接,则应按照 GB / T34590.8 — 2022 中第 15 章的要求对相应的安全活动进行剪裁。

6. 4. 5. 9 本要求适用于 T&B 的相关项的开发:如果开展安全活动,以确保未按照 GB / T34590 开发的系统或组件，满足集成到按照这些标准开发的相关项中所需的功能安全水平,则应按照GB / T34590. 8 — 2022 第 16 章的要求对这类安全活动进行剪裁。

6. 4. 6 安全活动的计划和协调

6. 4. 6. 1 按照 5. 4. 2. 7 的要求,安全经理应负责计划和协调组织所参与的功能安全活动。
注 1 :安全经理可将任务分配给具有所需技术、能力和资质的人员 (见 5.4. 4 )。
注 2 :根据相关项是全新开发、对现有相关项的修改或是对现有相关项环境的修改(见 6.4. 3 ),又或者要素是全新的还是复用的(见 6.4. 4 ),安全活动范围可以不同,并据此计划相应的安全活动。

6. 4. 6. 2 安全经理应负责维护安全计划并监控安全活动的进度是否按照安全计划进行。

6. 4. 6. 3 在组织内部应按照 5. 4. 2. 7 和 5. 4. 4 的要求,分配并沟通关于执行安全活动的责任。
注:安全经理负责计划和协调安全活动。其他人员可以负责细化计划(见 6.4. 6. 8 )或执行安全活动(例如,计划或执行集成和验证活动以及配置管理)。

6. 4. 6. 4 安全计划应:
a ) 在项目计划中被引用;或
b ) 包含在项目计划中,并使安全活动是可区分的。
注:在配置管理下,安全计划可交叉引用其他信息(见 GB / T34590.8 — 2022 的第 7 章)。交叉引用通常优于在不同工作成果或在配置管理下的其他文档里对活动的重复描述。

6. 4. 6. 5 安全计划应规定实现功能安全的活动计划和流程计划,包括:
a ) 将独立于项目的安全活动应用到项目特定的安全管理中,按照第 5 章;
b ) 如果适用,所剪裁的安全活动的定义,按照 6. 4. 5 ;
注 1 :例如,依据相关项层面(见 6. 4. 3 )或要素层面(见 6. 4. 4 )的影响分析结果进行剪裁。另参考 6. 4. 6. 7 。
c ) 安全活动的计划需要满足 GB / T34590.3 — 2022 、 GB / T34590.4 — 2022 、 GB / T34590. 5 —2022 、 GB / T34590. 6 — 2022 的要求;
d ) 按照 GB / T34590. 8 — 2022 中规定的支持过程的计划,如果适用,包括按照 GB / T34590. 8 —2022 的第 5 章,对定义与分布式开发中其他方的安全计划接口的开发接口协议( DIA )的引用;
e ) 集成和验证活动计划,按照 GB / T34590.3 — 2022 、 GB / T34590.4 — 2022 、 GB / T34590. 5 —2022 、 GB / T34590.6 — 2022 和 GB / T34590.8 — 2022 的第 9 章;安全确认活动计划,按照GB / T34590. 4 — 2022 第 8 章;
注 2 :作为工作成果,安全计划包括详细的集成、验证和安全确认计划,然而这些计划也可包含在其他文档中(见GB / T34590. 8 — 2022 的第 10 章)。
f ) 按照 6. 4. 9~6. 4. 12 规定的认可评审、功能安全审核和功能安全评估的日程安排;
注 3 : 6. 4. 9 给出的执行认可措施的人员的独立性水平在安全计划中定义。
注 4 :安全经理负责认可措施的日程安排。详细的认可措施计划由相应认可措施的负责人制定。
g ) 相关失效分析的计划,如果适用,按照 GB/ T34590.3 — 2022 、 GB / T34590. 4 — 2022 、 GB / T34590. 5 —2022 、 GB / T34590. 6 — 2022 、 GB / T34590. 9 — 2022 的第 7 章、 GB / T34590. 9 — 2022 的第 8 章;
注 5 :安全分析的目标和范围是在其计划中定义的,且取决于相应的子阶段和应用环境。
h ) 如果适用,提供候选项的在用证明,按照 GB / T34590. 8 — 2022 的第 14 章;
i ) 如果适用,提供软件工具置信度,按照 GB / T34590. 8 — 2022 的第 11 章。

6. 4. 6. 6 安全活动的计划应包括:
a ) 目标;
b ) 对其他活动或信息的依赖性;
c ) 负责执行活动的人员;
d ) 执行活动所需的资源;
e ) 起始时间、结束时间和持续时间;
f ) 相应工作成果的识别。

6. 4. 6. 7 当修改相关项和现有相关项环境时,按照 6. 4. 3 。当复用要素时,按照 6. 4. 4 :
a ) GB / T34590 的参考安全生命周期应根据相应影响分析的结果进行剪裁;
注 1 :在安全计划中定义了剪裁后的安全活动,该过程考虑了适用的生命周期阶段和子阶段(见 6. 4. 5 )。
b ) 应相应地识别、描述和返工需要创建或更新的受影响的工作成果;
注 2 :受影响的工作成果包括安全确认规范(见 GB / T34590. 4 — 2022 的第 8 章)。
c ) 如果安全文档不符合 GB / T34590 ,则应确定必要的活动以符合标准中的相应要求。
示例 1 :按照不同于 GB / T34590 的安全标准开发的要素,相应的安全文档不完全符合 GB / T34590 。
示例 2 :缺少安全文档或安全文档不完全符合 GB / T34590 的现有要素。

6. 4. 6. 8 安全计划应逐步更新,至少在每个阶段开始时更新。
注:至少在每个阶段的开始,安全计划都需更新,目的是细化该阶段的安全活动计划。安全计划可以在子阶段中进一步细化。

6. 4. 6. 9 安全计划要求的工作成果应在开发阶段保持最新状态,目的是在生产发布前和发布时保持对相关项或要素具有足够的代表性。

6. 4. 6. 10 如果是分布式开发,则客户和供应商均应针对各自的安全活动制定安全计划。
注:定义相应的开发接口协议,按照 GB / T34590. 8 — 2022 的第 5 章。

6. 4. 7 安全生命周期进程

6. 4. 7. 1 如果缺乏来自相关先前子阶段的信息,只有在即使缺乏信息也不会导致功能安全方面的不合理风险的情况下,才能开始后续子阶段。
注:对于缺乏信息可能危及项目的情况,需进行问题升级。

6. 4. 7. 2 按照 GB / T34590. 8 — 2022 中第 7 章、第 8 章和第 10 章的要求,每一项安全计划所要求的工作成果应分别服从配置管理、变更管理以及文档管理,且纳入管理的时间不迟于“产品开发:系统层面”阶段的启动时间(见 GB / T34590. 4 — 2022 )。

6. 4. 8 安全档案

6. 4. 8. 1 应按照安全计划建立安全档案,为实现功能安全提供论据

6. 4. 8. 2 安全档案宜逐步收录安全生命周期内的工作成果,以支持安全论证。
注 1 :在分布式开发的情况下,相关项的安全档案可以是客户和供应商的安全档案的结合,这些档案参考了相关方生成的工作成果的证据。然后相关项的整体论据由各方的论据支持。客户和供应商之间的接口在开发接口协议中定义(见 GB / T34590.8 — 2022 的第 5 章)。
注 2 :按照 6.4. 6 ,为了支持安全计划,可在工作成果可用之前确定预期的安全论证。为了支持按照 6. 4. 12. 3 进行的逐步的功能安全评估,随着工作成果的产生,安全档案可以逐步发布,为安全论证提供证据。

6. 4. 9 认可措施

6. 4. 9. 1 相关项及其要素的功能安全应被认可,基于:
a ) 按照表 1 和 6. 4. 10 的要求,认可评审判断关键工作成果,即表 1 所列工作成果,能否提供充足并令人信服的证据,证明其对实现功能安全的贡献,此过程应考虑 GB / T34590 相应的目标和要求。
注 1 :对表 1 中规定的和安全计划中要求的工作成果进行认可评审。
b ) 按照表 1 和 6. 4. 11 ,功能安全审核判断功能安全所需的流程的实施情况;
注 2 : GB / T34590 中定义了功能安全所需的参考流程。与相关项或要素有关的流程通过安全计划中引用或规定的活动来定义。
c ) 按照表 1 和 6. 4. 12 ,功能安全评估判断相关项实现的功能安全,或所开发的要素对实现功能安全的贡献。
注 3 :表 1 中定义的独立性的目的是确保客观、公正的观点,避免利益冲突。本文中所用的“独立性”一词指的是组织独立性。
注 4 :认可措施指南见附录 D 。
注 5 :认可措施的结果报告包括所分析的工作成果或流程文档的名称和版本号(见 GB / T34590.8 — 2022 的第 10章)。
注 6 :如果在认可措施完成后,相关项发生变更,则需要重新进行或补充相关的认可措施(见 GB / T34590.8 — 2022的 8.4. 5. 2 )。
注 7 :认可措施,如认可评审和功能安全审核,可以与功能安全评估合并、联合,以支持相关项类似变型的处理。

6. 4. 9. 2 在相关项开发过程中,实施认可措施的人员应能接触开展安全活动的人员和组织机构,并应得到其支持。

6. 4. 9. 3 实施认可措施的人员应有权限获取相关信息和工具。

6. 4. 10 认可评审

6. 4. 10. 2 认可评审应在生产发布前完成。

6. 4. 10. 5 只要评审根据按照表 1 以足够的独立性进行,认可评审和验证评审就可以合并进行。

6. 4. 11 功能安全审核

6. 4. 11. 1 当相关项和要素的安全要求的最高 ASIL 等级是 ASIL ( B )、 C 或 D 时,应按照 6. 4. 9 开展并在生产发布前完成功能安全审核。

6. 4. 11. 2 按照 5. 4. 4 和 5. 4. 2. 7 的要求,应委派负责进行功能安全审核的人员。

6. 4. 11. 3 功能安全审核可基于是否达到 GB / T34590 中流程相关的目标来判断。
注: GB / T34590 目标的实现与标准中相应要求相对应。
示例: 6.1 规定了第 6 章中要求的目标。

6. 4. 11. 4 负责执行功能安全审核的人员应提供包含对功能安全所要求的流程实施情况判断的评估报告,基于以下内容:
a ) 根据安全计划中定义或参考的活动定义,评估过程实施情况;
b ) 基于组织的专门的规则和流程(见 5. 5. 1 )对安全计划成果的评估;
c ) 如果提供论证,对其为什么实现了 GB / T34590 中流程相关目标进行评估；
注 1 :考虑到 6. 4. 11. 3 ,为了便于功能安全审核,负责安全活动的人员可提供论证来证明为何 GB / T34590 相应目标
已实现。
注 2 :符合 GB / T34590 所有相应的要求是已实现 GB / T34590 目标的一个充分理由。
d ) 对安全计划要求的工作成果是否可用的评估;
e ) 对安全计划要求的工作成果是否符合 GB / T34590. 8 — 2022 的 10. 4. 3 以及工作成果彼此间的一致性的评估;
f ) 如果适用,按照 5. 4. 2. 6 的改善建议,例如,存在不符合项的情况。
注 3 :功能安全审核与汽车软件过程改进及能力评定 ASPICE (见 ISO / IEC33000 )一起或同步进行,但是,按照6. 4. 12. 2 ,汽车软件过程改进及能力评定 ASPICE 􀇀 1) 的评估不足以执行功能安全评估。
注 4 :组织的流程定义同时符合多种标准,如 GB / T34590 和 ASPICE 的配置管理流程要求。这种流程的协调有助于避免重复工作或流程的不一致,对于协调后的流程,可给出组织的专门的流程对 GB / T34590 中要求和对ASPICE 要求的交叉引用。
注 5 :在项目早期阶段执行的功能安全审核对于识别流程中的不足是有益的。

6. 4. 12 功能安全评估

6. 4. 12. 1 当相关项或要素安全要求的最高 ASIL 等级为( B )、 C 或 D 时,应按照 6. 4. 9 的要求开展功能安全评估。以判断相关项已实现的功能安全,或已开发要素对实现功能安全的贡献。

6. 4. 12. 2 功能安全评估可基于对 GB / T34590 的各项目标是否达到来判断。
注: GB / T34590 的目标实现是根据开发时这些标准的相应要求、技术解决方案的当前技术水平和适用的工程领域知识来判断的。
示例: 6. 1 中规定了第 6 章要求的目标。

6. 4. 12. 3 功能安全评估:
a ) 按照 6. 4. 6. 5f )进行计划;
b ) 最迟宜在系统级产品开发之初进行规划;
c ) 宜在产品开发过程中逐步执行;
d ) 应在生产发布前完成。
示例:功能安全评估的示例议程见附录 E 。

6. 4. 12. 4 按照 5. 4. 2. 7 和 5. 4. 4 的要求,应委派一名或多名人员开展功能安全评估。被委派的人员应提供一份包含对功能安全实现程度的评判的报告。

6. 4. 12. 5 负责进行功能安全评估的人员应被授予权力,根据他们的自由裁量权进行功能安全评估,包括:
a ) 按照 6. 4. 12. 7 要求在功能安全评估范围内,安全活动及其结果的广度和深度需被评估;
b ) 按照 6. 4. 9. 3 提供的信息;
c ) 按照 6. 4. 9. 2 的要求,实施功能安全评估的必需支持,例如负责相关工作成果的人员要在场。

6. 4. 12. 6 按照 6. 4. 9. 2 和 5. 4. 4 的要求,功能安全评估员可以委派一名或多名助理来支持功能安全评估的执行。这些人员可能缺乏与相应相关项、要素或工作成果的开发人员之间的独立性,但其独立性至少应达到表 1 所定义的 I1 ,评估人员应对其输入进行评估,以确保给出的意见是公正的。
注:功能安全评估员需对功能安全评估的结果负责

6. 4. 12. 7 功能安全评估范围应包括：
a ) 安全计划及安全计划要求的所有工作成果;
注 1 :功能安全评估员可以剪裁被评审的特定工作成果的详细程度。但是,表 1 中列出的安全计划要求的那些工作成果值得特别注意。
注 2 :功能安全评估员考虑包含双向可追溯性的需求管理(见 GB / T34590.8 — 2022 的第 6 章)是否已被充分实施。
注 3 :对相应工作成果的检查为判断是否实现某一 GB / T34590 目标(见 6. 4. 12. 2 )提供了支持。
b ) 功能安全要求的流程;
注 4 :对已实施的流程的评估可基于功能安全审核的结果以及由此所产生的纠正措施(如有)。
c ) 在相关项或要素开发过程中,可评估已执行或实施的安全措施的恰当性和有效性;
注 5 :功能安全评估检查与生产、运行、服务和报废有关的需求的适应性。关于生产,在生产过程能力分析期间检查此类要求的正确实施(见 GB / T34590.7 — 2022 的 5. 4. 2. 2 和 GB / T34590. 7 — 2022 的 6. 4. 1. 3 )。
d ) 考虑到 GB / T34590 的相关目标的实现,关于为什么实现功能安全的论证(如果可以提供);
注 6 :考虑到 6. 4. 12. 2 ,负责创建工作成果的人员提供论据来证明为何 GB / T34590 的相应目标已实现,从而促进功能安全评估的进行。
注 7 :符合所有相应的 GB / T34590 要求是实现 GB / T34590 目标的充分理由。
e ) 安全档案中提供的论据;
f ) 安全异常关闭的理由,按照 5. 4. 3 。
注 8 :在分布式开发的情况下,在客户及其供应商处执行功能安全评估活动(见 GB / T34590.8 — 2022 的第 5 章)。供应商进行的功能安全评估可判断是否满足客户的安全要求,并判断已开发的要素或工作成果对实现功能安全的贡献。供应商按里程碑节点并以开发接口协议中定义的形式向客户提供功能安全评估报告 (见GB / T34590. 8 — 2022 的 5. 4. 5 )。客户进行的功能安全评估会考虑供应商的安全评估报告(见 6. 4. 12. 8 )。最后,如果客户是车辆制造商,则功能安全评估包括对集成在目标车辆中的相关项已实现功能安全的判断。

6. 4. 12. 8 功能安全评估应考虑:
a ) 其他认可措施的计划[见 6. 4. 6. 5f )];
b ) 认可评审和功能安全审核的结果;
c ) 如果适用,先前的功能安全评估的建议和采取的纠正措施 (见 6.4.12.9~6.4.12.13 和GB / T34590. 8 — 2022 的 8. 4. 5. 2 );
d ) 如果适用,供应商按照 GB / T34590. 8 — 2022 中第 5 章的开发接口协议,开发的要素或工作成果的功能安全评估活动的结果。

6. 4. 12. 9 功能安全评估报告应包括对相关项的功能安全接受、有条件接受或拒绝的建议,或所开发的要素/工作成果对相关项功能安全的贡献。

6. 4. 12. 10 按照 6. 4. 12. 9 的要求,功能安全评估报告可包括对相关项的功能安全、或所开发的要素或工作成果对功能安全的贡献做出有条件接受的建议,以所确定的接受条件的决议为准。
注:在分布式开发的情况下(见 GB / T34590.8 — 2022 的第 5 章),供应商的功能安全评估报告需包括关于已开发要素或工作成果的接受、有条件接受或拒绝的建议。

6. 4. 12. 11 按照 6. 4. 12. 10 ,如果功能安全评估报告建议是对已实现的功能安全有条件接受,功能安全评估报告中应包括接受条件。

6. 4. 12. 12 按照 6. 4. 12. 10 ,如果功能安全评估报告建议是对已实现的功能安全有条件接受,则应采取必要的纠正措施,以解决功能安全评估报告中记录的接受条件。

6. 4. 12. 13 按照 6. 4. 12. 9 ,如果功能安全评估报告建议是对已实现的功能安全拒绝,则:
a ) 应采取充分的纠正措施;
b ) 应重新进行功能安全评估。

6. 4. 13 生产发布

6. 4. 13. 1 在生产发布之前,应按照 6. 4. 8 提供安全档案

6. 4. 13. 2 在生产发布之前,应按照 6. 4. 9~6. 4. 12 提供适用的认可措施报告。

6. 4. 13. 3 仅当有足够证据证明对功能安全实现有信心时,才可批准相关项或要素的生产发布。
注:通过以下方式提供实现功能安全的信心证据:
———认可措施的结果,特别是包含在功能安全评估报告中的建议,如果适用,按照 6. 4. 12. 9 ;
———安全档案

6. 4. 13. 4 生产发布的功能安全文档应包括以下信息:
a ) 负责发布的人员的名字和签名;
b ) 发布相关项或要素的版本;
c ) 发布相关项或要素的配置;
d ) 发布日期。

6. 4. 13.5 在生产发布时,应提供嵌入式软件的基线 (包括标定数据)和硬件的基线,并应按照GB / T34590. 8 — 2022 中第 10 章的规定进行记录。

6. 5. 4 安全档案,由 6. 4. 8 得出。

6. 4. 8 安全档案

6. 4. 8. 1 应按照安全计划建立安全档案,为实现功能安全提供论据

6. 5. 5 认可措施报告,由 6. 4. 9~6. 4. 12 得出。

6. 4. 9 认可措施

6. 4. 9. 2 在相关项开发过程中,实施认可措施的人员应能接触开展安全活动的人员和组织机构,并应得到其支持。

6. 4. 9. 3 实施认可措施的人员应有权限获取相关信息和工具。

6. 4. 10 认可评审

6. 4. 10. 2 认可评审应在生产发布前完成。

6. 4. 10. 5 只要评审根据按照表 1 以足够的独立性进行,认可评审和验证评审就可以合并进行。

6. 4. 11 功能安全审核

6. 4. 11. 1 当相关项和要素的安全要求的最高 ASIL 等级是 ASIL ( B )、 C 或 D 时,应按照 6. 4. 9 开展并在生产发布前完成功能安全审核。

6. 4. 11. 2 按照 5. 4. 4 和 5. 4. 2. 7 的要求,应委派负责进行功能安全审核的人员。

6. 4. 11. 4 负责执行功能安全审核的人员应提供包含对功能安全所要求的流程实施情况判断的评估报告,基于以下内容:
a ) 根据安全计划中定义或参考的活动定义,评估过程实施情况;
b ) 基于组织的专门的规则和流程(见 5. 5. 1 )对安全计划成果的评估;
c ) 如果提供论证,对其为什么实现了 GB / T34590 中流程相关目标进行评估；
注 1 :考虑到 6. 4. 11. 3 ,为了便于功能安全审核,负责安全活动的人员可提供论证来证明为何 GB / T34590 相应目标已实现。
注 2 :符合 GB / T34590 所有相应的要求是已实现 GB / T34590 目标的一个充分理由。
d ) 对安全计划要求的工作成果是否可用的评估;
e ) 对安全计划要求的工作成果是否符合 GB / T34590. 8 — 2022 的 10. 4. 3 以及工作成果彼此间的一致性的评估;
f ) 如果适用,按照 5. 4. 2. 6 的改善建议,例如,存在不符合项的情况。
注 3 :功能安全审核与汽车软件过程改进及能力评定 ASPICE (见 ISO / IEC33000 )一起或同步进行,但是,按照6. 4. 12. 2 ,汽车软件过程改进及能力评定 ASPICE 􀇀 1) 的评估不足以执行功能安全评估。
注 4 :组织的流程定义同时符合多种标准,如 GB / T34590 和 ASPICE 的配置管理流程要求。这种流程的协调有助于避免重复工作或流程的不一致,对于协调后的流程,可给出组织的专门的流程对 GB / T34590 中要求和对ASPICE 要求的交叉引用。
注 5 :在项目早期阶段执行的功能安全审核对于识别流程中的不足是有益的。

6. 4. 12 功能安全评估

6. 4. 12. 4 按照 5. 4. 2. 7 和 5. 4. 4 的要求,应委派一名或多名人员开展功能安全评估。被委派的人员应提供一份包含对功能安全实现程度的评判的报告。