​​​​

       继续学习AUTOSAR，看一下官方文档中安全扩展相关部分。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_系统设计

       5 安全完整性等级

       本规范旨在支持 ISO 26262 [2] 的汽车安全完整性等级 (ASIL)。 其他安全完整性级别将不会被考虑并且超出了本文档的范围。

       ASIL 在 ISO 26262-3 的概念阶段被确定为 HARA 的一部分，并分配给每个安全目标。 系统设计 - 最后是软件架构 - 将通过将安全要求分配给技术/软件架构（第 3 节，有关安全要求的分配，请参阅第 6 节）继承此 ASIL 作为属性。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_系统设计_02

       安全要求的 ASIL 属性

       根据第 4 节定义的安全要求应获得 ASIL 属性。  ASIL 存储在 AdminData 中，其中包含一个带有 gid=”SAFEX” 的 Sdg 数据。 该元素的内容应包含具有属性 gid=”ASIL” 的 Sd 元素。 此属性的有效值为上面的一系列数值。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_autosar_03

       请注意，括号表示法用于表示分解的安全要求。 在本规范中，我们将原始 ASIL（即括号中的值）称为分解前的上下文 ASIL，因为它属于安全目标的上下文。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_软件架构_04

       安全目标没有分解的 ASIL

       如果安全要求是 SAFETY_GOAL 类型，则 ASIL 属性的有效值限于：QM、A、B、C 或 D。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_系统设计_05

       AUTOSAR 元素的 ASIL（可选）

       如果至少分配了一项安全要求，则所有 AUTOSAR 元素都应获得 ASIL 属性。  ASIL 应作为带有 gid=”SAFEX” 的 Sdg 数据添加到 XML 中的 AdminData 部分。  XML 内容应包含属性为 gid=”ASIL”的 Sd 元素，有效值与 [TPS_SAFEX_00201] 中的相同。

       请注意，根据 [TPS_SAFEX_00202]，元素上的 ASIL 是可选的。如果未在元素中指定 ASIL，则语义是它从所有分配的安全要求中衍生为最高 ASIL。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_autosar_06

       ASIL 值的一致性

       AUTOSAR 元素的 ASIL 和分配的安全要求应该是一致的。 如果一个元素的值等于或高于分配的安全要求的最大 ASIL，则 ASIL 是一致的。

       请注意，由于各种原因，AUTOSAR 元素的 ASIL 可能高于安全要求的 ASIL。 例如，一个 SWC 可能被设计为在更高的安全完整性环境中重用，因此被评为更高的 ASIL。 然而，对于分解的需求，可以解释在比较 ASIL 值时如何考虑上下文 ASIL。

       有关安全要求中 ASIL 属性的示例，请参见清单 4.1。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_autosar_07

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_autosar_08

       6 安全要求的可追溯性和分配

       ISO 26262 安全要求的基本特征是可追溯性的管理和维护。 本规范将安全要求的可追溯性称为（安全）要求与其他要素之间不同类型链接的通用术语。 主要区分三种类型的轨迹：

       1. 两级安全要求之间的细化关系，例如有助于功能安全要求的技术安全要求（见 ISO 26262-8，条款 6.4.3.1.a）。 这个概念类似于AUTOSAR规范本身的上游追踪，会以同样的方式实现。

       2. 从安全需求到软件架构元素的分配关系，例如分配给 AUTOSAR SWC 端口的 SW 安全要求（参见 ISO 26262-8，第 6.4.2.3 条）。

       3. 从安全要求到安全措施/机制的映射关系，例如映射到端到端保护安全机制的 CRC 安全要求（参见 ISO 26262-4，第 6.4.1、6.4.2 和 6.4.6 条）。

       请注意，安全要求的可追溯性不仅仅指当前 AUTOSAR 文档元模型中的文本元素之间的引用（参见 [TPS_GST_00243]）。 因此，在 AdminData 块中使用 Referrable 引用（通过 sdx 元素）管理不同的关系类型。

       分解是具有架构含义的细化关系的特殊化。 安全要求的分解需要系统架构中存在两个独立的元素，因此可以保证不受干扰。 为了通过分解的安全需求追溯到软件的这些分解，我们正在提高实施者的意识并启用相同的验证，例如在集成测试期间。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_软件架构_09

       安全需求细化关系

       安全需求的细化关系应通过轨迹关联来表示。 轨迹的方向具有语义“细化”。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_autosar_10

       安全要求分解

       分解应在分解的安全要求中规定。 为此，需求应接收一个 AdminData 条目，该条目包含一个名为 gid=”DECOMPOSITION”的 Sdg 元素，该元素具有对分解的安全需求的 sdx（即可引用）的两个引用。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_系统设计_11

       分解为两个安全要求

       [TPS_SAFEX_00302] 的分解应准确列出两个分解的安全要求（不是更多）。

889_AUTOSAR_TPS_SafetyExtensions3_完整性等级与功能安全需求跟踪1_软件架构_12

       独立要求链接

       如果安全要求表达了实现分解元素不受干扰的方法，则除了分解的要求之外，还应在分解的安全要求中列出它们。 因此，分解后的安全需求的 AdminData 在一个带有 gid=”INDEPENDENCE”的 Sdg 元素中接收一个单独的引用（sdx 条目）。

       请注意，分解的和独立的安全需求可能会另外收到对被分解的原始安全需求的“反向”跟踪。 通过这种方式，可以通过不了解安全扩展的工具无缝导航整个可追溯性层次结构。

       这部分主要是看了功能完整性等级的相关介绍以及部分功能安全需求跟踪的要求和方法，后者并没有完全完成梳理，后面会继续做这方面的整理。