功能安全入门02---标准解读05针对Part09以安全完整性等级为导向和以安全为导向的分析

此部分非原创，搬运及修改来自：
《GB/T 34590.9-2017《道路车辆 功能安全 第9部分：以汽车安全完整性等级为导向 和以安全为导向的分析》解读》 作者：童菲 尚世亮等

5.1导读

GB/T《道路车辆功能安全》第9部分由八个章节组成，其中第1～4章节为通用内容，与本标准其他部分基本一致。第5～8章节为第9部分的重点内容，涵盖“***关于ASIL剪裁的要求分解”“要素共存的准则”“相关失效的分析”和“安全分析”***等四个方面，详细定义了“以汽车安全完整性等级为导向和以安全为导向的分析”的工作方法及要求。 本文依照第9部分的结构顺序，通过对相关规定的详细分析，结合实例阐述，逐一解读了上述四个核心内容的注意点，有助于理解标准内容，并初步掌握基础的分析方法。

5.2 关于ASIL剪裁的要求分解

5.2.1 目的

旨在为安全要求分解成冗余的安全要求提供一定的规则和指导，进而允许在更细节层面的ASIL剪裁。这种设计过程中的ASIL剪裁又称为 “ASIL分解”，可应用于相关项或要素的功能安全要求、技术安全要求、软硬件安全要求等。

如果充分独立的架构要素，冗余的实现一个安全要求，则可 应用“ASIL分解”将一个可能更低的ASIL等级分 配给这些分解后的安全要求。如果架构要素不是充分独立的，则冗余要求和架构要素须继承初始的ASIL等级，维持现状。因此，在ASIL分配过程中， 这种分解方法有助于充分独立的架构要素在架构决策中获得分解后的、较低的ASIL等级，而非继承初始的ASIL等级，这对降低整个系统的开发复杂度及成本是很有益处的。

5.2.3 ASIL剪裁的注意点

ASIL的分解需在充分独立、冗余实现同一安全需求的要素之间才能进行，ASIL分解可以多次使用以支持ASIL的多级分解，但应通过在括号中给出安全目标的ASIL等级，对每个分解后的ASIL等级做标注。ASIL分解方案可参见标准原文。
ASIL分解有以下七大注意点须给予重点关注：
（1）不适用ASIL 分解的情况，包括： ·同构冗余，例如通过复制设备或复制软件实 现冗余，这会引入共因失效，不满足“独立性”。 ·在多通道架构设计中用来确保通道选择或切 换的要素，这会引入级联失效，不满足“独立性”。
（2）系统层面ASIL分解时，可以在预期功能及 其相应的安全机制间进行ASIL分解，但相关安全 机制宜被赋予分解后的最高ASIL等级。这是因为 与预期功能相比，安全机制具备更低的复杂度和更 小的规模，从成本的角度，它更易满足高ASIL 等 级。
（3）硬件层面ASIL分解时，针对随机硬件失效 的要求，包括硬件架构度量的评估和由于随机硬件 失效导致违背安全目标的评估，在ASIL分解后仍 保持不变。
（4）软件层面ASIL分解时，应在系统层面检查 执行分解后要求的要素间的充分独立性，且应在软 件层面、硬件层面或系统层面采取适当的措施来获 得充分的独立性。
（5）当ASIL D分解成[ASIL B(D) + ASIL B(D)]时， 需要遵守额外要求： ·应按照ASILC的要求来定义分解后的安全要求，因为与ASIL B相比，ASIL C要求更正式的标 记法，从而更有效的避免系统性失效，并降低两个 ASIL B(D)实施间的相关性。 ·如果用相同的软件工具开发分解后的要素，那 么这些软件工具应考虑使用开发ASIL D相关项或 要素的软件工具，并符合第8部分中软件工具使用 的置信度。
（6）在“认可措施”方面，应按照安全目标的 ASIL等级实施，并具备分解后要素充分独立性的 证据。
（7）在集成及后续活动方面，针对“设计过程 中应用了分解的每个层面”，应按照分解前的ASIL 等级要求，开展对分解后的要素的相关集成活动及 后续活动。

5.3 要素共存的准则

5.3.1 目的

通常，当某个要素由几个子要素组成时， 应依照适用于该要素的最高ASIL等级的相应措施来开发每个子要素。如果存在分配了不同ASIL等 级的子要素共存情况，或未分配ASIL等级的子要素与安全相关的子要素共存情况，如能避免将部分子要素的ASIL等级提高到整个要素的ASIL等级， 则对降低开发复杂度及成本是有益的。

5.3.2 关键术语

研究子要素之间的共存性，即互相之 间“免于干扰”。所谓“干扰”，是指由未分配ASIL等级的子要素或分配了较低ASIL等级的子要素引 发分配了较高ASIL等级的子要素的失效，进而导 致违背了要素的安全要求。
主要有“失效”“免于干扰”等。

5.3.3 要素共存的注意点

对“要素共存”的分析可用于设计过程的任意细化步骤，它平行于架构要素和子要素的安全要求 分配工作。典型的应用是在系统设计、硬件设计或 软件架构设计的子阶段。分析时应考虑两方面的内 容，其一是分配到要素的每个安全要求，其二是要 素的每个子要素。首先，明确要素的各个子要素以 及分配到各子要素的安全要求和ASIL 等级，然后， 对各子要素的失效进行分析，判断是否会影响到其 他子要素，是否存在干扰和免于干扰。

5.4 相关失效的分析

5.4.1 相关失效的分析

旨在识别出使给定要素间所要求的独立性无效或使免于干扰无效，并违背安全要求或安全目标的单一事件或原因。相关失效主要包括共因失效和级联失效，这些失效可同时显现， 或在足够短的时间间隔内产生同时失效的效果。

5.4.2 相关失效分析的注意点

相关失效分析的时候需要充分考虑架构的特征，例如是否存在相似的和不相似的冗余要素，是 否对相同的软件或硬件要素分配了不同功能，是否 考虑了功能的分割、软件要素的分隔以及硬件要素 间的物理距离（包括有隔离或无隔离）等，此外还 要充分考虑功能及其相关安全机制，及共同的外部 资源等方面内容。 对于每个识别出的相关失效，需要进一步评 估这些失效的潜在可能性，以判定其合理性。例如， 考虑所分析相关项或要素的运行工况，以及其各种 运行模式，确定合理的相关失效内容。然后，针对 所有合理的相关失效，制定并执行解决措施.

5.5安全分析

目的 安全分析旨在检查相关项及要素的功能、表现及设计中的故障和失效后果，它有助于识别出在先前危害分析和风险评估过程中未被发现的、新的功能性危害或非功能性危害。
安全分析的使用范围很广，可用于确认安全目标及安全概念，验证安全概念和安全要求，识别可导致违背安全目标或安 全要求的条件，识别故障探测或失效探测的额外要 求，以及制定探测故障或失效所需的响应行为/响 应措施等方面。

5.5.1安全分析的方法

基于不同的分类原则， 可分为“定性分析”与“定量分析”，或者“归纳分 析”与“演绎分析”。 （
1）“定性分析”与“定量分析”
“定性分析”方法可用于识别失效，但不能预测失效频率，
“定量分析”方法可用于预测失效的 频率。
前者主要包括系统、设计或过程层面的定性 FMEA、定性FTA、危害与可操作性分析(HAZOP) 和定性ETA等，
后者包括定量FMEA，定量FTA，定量ETA，马尔科夫(Markov)模型以及可靠性框图等。
这两种分析方法都依赖于对相关的故障类型和故障模型的了解。此外，“定量分析”还要求掌握硬件要素定量失效率的知识，但它仅针对随机硬件失效分析，并不适用于系统性失效分析。
在随机硬件失效中，“失效模式”和“失效率”是描述失效的两个重要参数， 以硬件要素电容为例，其失效模式有开路（失效率 20%）和短路（失效率80%）。 这里的失效模式和失效率可由行业标准得到，例如IEC/TR 62380、IEC 61709、MIL HDBK 217 F notice 2、RIAC HDBK 217 Plus、UTE C80811、NPRD 95、EN 50129:2003 Annex C、IEC 62061:2005 Annex D、RIAC FMD97 和 MIL HDBK 338等。不同的标准可能引入不同的失效率数据， 在直接使用数据时，如果需对多个来源中的失效率进行组合，可先在不同标准的数据上采用“度量转换”（即应按一个比例因子进行换算以保持一致。 如果两个失效率来源间的比例因子存在根据，则换算是可行的）。
需特别注意的是，仅通过“失效率” 来进行定量的失效分析是不完备的，还须结合定性分析才行。“定量分析”可认为是对“定性分析”的 补充，用于验证硬件设计是否符合已定义的硬件 架构度量评估目标值和因随机硬件失效导致违背 安全目标的评估目标值。
（2）“归纳分析”与“演绎分析” 安全分析的另一种分类原则是基于分析的执行方法给出的，可分成“归纳分析”和“演绎分析”。
“归纳分析”是由下而上的分析方法，由已知 的原因预见未知的影响，例如系统、设计和过程 FMEA、ETA和马尔科夫模型等都是“归纳分析”方 法；
“演绎分析”是由上而下的方法，由已知的影 响探寻未知的原因，例如FTA和可靠性框图等均属 于“演绎分析”方法。 “归纳分析”先对单元组件的失效模式进行分析， 研究其对组件的影响，然后一步一步往上分析直至 对整车级的失效影响；“演绎分析”先从整车级失 效开始，分析可能导致该失效的潜在原因，然后一 步一步往下分析直至最底层的单元组件失效。因此， 这两类分析方法虽然分析思路不同，但分析结果是 互为补充的。

5.5.2 安全分析的注意点

在具体开展安全分析的时候，推荐同时采用不 同类型的分析方法，以尽可能的提升分析结果的全 面性。
例如，在系统层面，既开展系统级FMEA，从下至上的进行归纳分析，又考虑系统级故障的FTA， 从上至下的进行演绎分析；在硬件层面，既开展定 性分析，识别失效，同时也做定量分析，预测失效 的频率。通过不同类型的分析方法，尽可能的发现 各种潜在失效，进而完善安全机制。 安全分析能帮助识别相关安全目标或安全要 求是否得到了满足，因此，由安全分析得出的措施

应作为产品开发的一部分，在系统层面、硬件层面 或软件层面进行实施，并且应利用安全分析中的故 障模型和分析结果来确定是否需要额外的安全相 关测试案例。对于在产品开发过程中由安全分析新 识别出的、未被安全目标覆盖的危害，应按照变更 管理要求，引入到危害分析和风险评估中，并依次 开展后续各子阶段的相关工作。