继续看AUTOSAR的文档，这次看一下安全扩展相关的部分。
1 介绍
1.1 范围 本文档收集了 AUTOSAR 模型的安全方面的需求，并将其纳入 AUTOSAR 模板。
安全扩展的主要目标是使 AUTOSAR 系统的安全相关信息能够作为 AUTOSAR 模板的一部分进行交换。 这将为 AUTOSAR 元素、安全措施和 AUTOSAR 安全机制的安全需求的必要可追溯性奠定基础。 它还将确保在系统设计、实现和配置过程中为 AUTOSAR 元素提供适当的安全完整性级别，并且它们可以进行约束检查。
在本文档的上下文中，功能安全机制是一个具体的产品部分，例如内存保护。 它们被视为功能安全措施的专业化，其中还包括流程步骤，如审查。 该定义与 ISO 26262-1 [1] 中针对这些术语给出的定义一致。
AUTOSAR 安全扩展规范 [2] 将满足本文档中收集的需求。
看过好几份文件都有这样的一段，基本是套话没有实质的梳理解释价值，跳过，后续其他的类似章节也跳过。
1.3 指南
应参考现有规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求都应具有以下特性：
• 冗余
需求不得在一个需求或其他需求中重复。
• 清晰性
所有需求只允许一种解释的可能性。必须定义术语表中未使用的技术术语。
• 原子性
每个需求应仅包含一个需求。如果一个需求不能被拆分成进一步的需求，那么它就是原子的。
• 可测试性需求应可通过分析、审查或测试进行测试。
• 可追溯性 需求的来源和状态应始终可见。
连续看了几份文件，似乎这一部分也是一个重复的片段，后面也不再重复梳理了。同样，几个跟踪矩阵也不再列数。
4 需求
本章描述了推动定义安全扩展规范 [2] 工作的所有需求。
安全需求
AUTOSAR 模型中可表达的安全需求
安全需求应通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达。
AUTOSAR 中所有需求的一致规范和表示，包括安全需求及其规范项目。
安全需求至少与其他需求一样具有表现力
安全需求至少应能覆盖与 AUTOSAR 中的其他需求相同类型的信息。此外，请遵循 ISO 26262-8 的需求管理需求，参见 [1]。
ISO 26262 [1] 等安全标准定义了安全需求定义的最低需求。此外，需要对 AUTOSAR 中的安全和非安全需求使用类似结构的统一定义。
URI 的安全需求描述
应该可以通过 URI 将 AUTOSAR 模型内的安全需求定义与该 AUTOSAR 模型外的该需求规范相关联。
在实践中使用了几种交换需求的技术方法。这包括需求交换格式 (ReqIF) 或基于专有工具的交换。通过 URI 引用外部需求定义的可能性，可以在 AUTOSAR 模型内建立可追溯性，同时避免重复数据及其典型的负面影响。
安全需求可区分
安全需求应与 AUTOSAR 模型中的其他需求区分开来。
安全标准的规定需要仅适用于安全需求。 这保证例如，用于可追溯性或 ASIL 相关的度量或约束。因此，有必要明确确定安全需求。
唯一可识别的安全需求
安全需求应是唯一可识别的。
这是满足安全标准需求所必需的。
安全需求的状态信息
应能规定安全需求的状态。
安全需求的层次
应能规定安全需求的层次。
安全需求分解
应能将一个安全需求分解为两个独立的安全需求。
ASIL 分解是 ISO 26262 中提供的一个概念，用于通过将安全需求拆分为独立的安全需求来降低安全需求的 ASIL。 ASIL 分解也应可用于 AUTOSAR 系统。
独立性需求规范
应该可以指定作为特殊安全需求的独立需求，并将其与安全需求的分解相关联。
ASIL 分解只有在可以确保具有较低 ASIL 的结果安全需求的独立性时才允许。 这导致对独立性的需求与分解明显相关。
安全完整性等级
安全需求的 ASIL 属性
应可以为安全需求指定 ASIL 属性。 属性的值至少应以明确的方式覆盖 ISO 26262 中列出的可能的 ASIL 值。
确保系统功能安全的必要措施取决于适用的 ASIL。 将 ASIL 分配给系统元素是通过安全需求完成的。不遵守 ASIL 标准可能会导致系统不安全。
AUTOSAR 元素的 ASIL 属性
应该可以为作为 AUTOSAR 模型一部分的任何 AUTOSAR 元素指定 ASIL 属性。 属性的值至少应以明确的方式覆盖 ISO 26262 中列出的可能的 ASIL 值。
这允许在安全要求和 AUTOSAR 元素之间交叉检查 ASIL 值。 使用例如安全要素脱离上下文方法 (SEooC)的时候尤为重要，参见 ISO 26262-10 [1]。
这部分小结暂且到此，主要看了一下安全的需求以及安全完整性的描述。关于完整性的描述，其实主要的一个参考点就是ISO26262，这里把这部分要求作为了对工具设计的要求。
