# 安全扩展规范（Specification of Safety Extensions） | 字段 | 内容 | |---|---| | **文档标题** | 安全扩展规范（Specification of Safety Extensions） | | **文档所有者** | AUTOSAR | | **文档责任方** | AUTOSAR | | **文档标识号** | 671 | | **文档状态** | Final（正式发布） | | **所属 AUTOSAR 标准** | Classic Platform（经典平台） | | **所属标准版本** | 4.4.0 | --- ## 文档变更历史（Document Change History） | 日期 | 版本 | 变更人 | 变更描述 | |---|---|---|---| | 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 | | 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation | | 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 改进了安全需求分解关系的建模；细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation | | 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation | | 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 基于概念"Safety Extensions"的初始规范 | --- ## 目录（Table of Contents） 1. [引言](#1-引言) - 1.1 [概述](#11-概述) - 1.2 [范围](#12-范围) - 1.3 [文档约定](#13-文档约定) - 1.4 [缩写](#14-缩写) - 1.5 [术语词汇表](#15-术语词汇表) - 1.6 [指南](#16-指南) 2. [需求追踪](#2-需求追踪) 3. [安全扩展概述](#3-安全扩展概述) 4. [安全需求](#4-安全需求) 5. [安全完整性等级](#5-安全完整性等级) 6. [安全需求的可追溯性与分配](#6-安全需求的可追溯性与分配) 7. [安全措施](#7-安全措施) 8. [应用说明](#8-应用说明) 9. [附录 A 提到的类表](#附录-a-提到的类表) --- ## 参考文献 - **[1]** Requirements on Safety Extensions `AUTOSAR_RS_SafetyExtensions` - **[2]** Standardization Template `AUTOSAR_TPS_StandardizationTemplate` - **[3]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org - **[4]** Methodology `AUTOSAR_TR_Methodology` --- ## 1 引言 ### 1.1 概述 本文档包含 AUTOSAR 安全扩展的规范，并实现 [1] 中陈述的需求。安全扩展通过现有的（通用）AUTOSAR 元模型概念表达。在后续版本中可能会引入原生元模型概念。第 3 节提供了关于这些扩展的更详细概述。 ### 1.2 范围 本文档的范围涵盖了应在 AUTOSAR 上下文中实现 ISO 26262 开发的安全扩展。这些扩展允许安全信息的标准化交换，并提供 ISO 26262 要求的不同供应商和工具之间一致管理的基础。 本文档不是关于功能安全的一般介绍，也不是关于 ISO 26262 的具体介绍。其他安全标准或指南（如 IEC 61508 或 MISRA）不在范围内。 ### 1.3 文档约定 AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表，参见标准化模板的"Support for Traceability"章节（[2]）。 应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求，参见标准化模板的"Support for Traceability"章节（[2]）。 ### 1.4 缩写 | 缩写 | 含义 | |---|---| | **ASIL** | Automotive Safety Integrity Level（汽车安全完整性等级） | | **DC** | Diagnostic Coverage（诊断覆盖率） | | **ECC** | Error Correction Code（纠错码） | | **EDC** | Error Detection Code（错误检测码） | | **HARA** | Hazard Analysis and Risk Assessment（危险分析与风险评估） | | **HW** | Hardware（硬件） | | **FSC** | Functional Safety Concept（功能安全概念） | | **TSC** | Technical Safety Concept（技术安全概念） | | **SEooC** | Safety Element out of Context（上下文外安全元素） | | **SM** | Safety Mechanism or Measure（安全机制或措施） | | **SW** | Software（软件） | | **SWC** | Software Component（软件组件） | | **URI** | Uniform Resource Identifier（统一资源标识符） | | **URL** | Uniform Resource Locator（统一资源定位符） | **表 1.1**：缩写 ### 1.5 术语词汇表 通常，本文档将使用 ISO 26262-1 词汇（参见 [3]）中定义的安全相关术语。为便于说明，表 1.2 列出了一些与 AUTOSAR 相关的术语及其定义。 | 术语 | 定义 | |---|---| | **ASIL 属性** | 系统元素的 ASIL 指定了为避免不合理的残余风险而需要应用的 ISO 26262 必要需求和安全措施。详见第 5 节。 | | **故障、失效、错误** | 故障（Fault）是一种异常状况，可能导致硬件或软件元素失效。错误（Error）描述了值或条件中产生的偏差，是（一组）故障的结果。失效（Failure）定义了硬件或软件元素执行其功能的能力的终止（参见 [3]）。故障包括系统性软件故障（即"缺陷"、"Bug"）、随机硬件故障（例如由于设备的应力 / 老化）以及系统性硬件故障。 | | **安全状态** | 安全状态总是在系统级别描述（参见 [3]）。某个软件状态可能是此"系统状态"的一部分，或者这种关系未定义（例如，如果运行软件的微控制器在安全状态下被关闭）。 | | **安全机制** | 安全机制是一种技术解决方案 [...]，用于检测故障或控制失效以实现或维持安全状态（参见 [3]）。本规范中使用的术语正是这种更广泛的含义，因此不仅 AUTOSAR 安全机制（"安全特性"）可以被描述，而且系统的任何 HW/SW 或组合解决方案都可以被描述，因为 AUTOSAR 软件是为这些解决方案实现的（参见第 7 节）。 | | **安全措施** | 安全措施是避免系统性失效以及检测随机硬件失效或控制失效的活动或解决方案（参见 [3]）。因此，安全措施可能仅定义一个过程活动，例如专用测试方法、附加的代码验证等（参见第 7 节）。本规范将使用术语"安全措施"来概括开发期间的活动以及实施到系统中的安全措施。 | | **安全需求** | ISO 26262 定义了安全需求的层次结构：安全目标、技术、硬件和软件。在本文档中，安全需求可以是其中任何一种。有关详细信息，请参考 ISO 26262-3、4 和 9。 | **表 1.2**：术语词汇表 ### 1.6 指南 应引用现有的规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性： - **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。 - **清晰性（Clearness）**：所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。 - **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求，则该需求是原子的。 - **可测试性（Testability）**：需求应通过分析、评审或测试进行测试。 - **可追溯性（Traceability）**：在任何时候都应可见需求的来源和状态。 --- ## 2 需求追踪 下表引用 [1] 中指定的需求，并将其链接到这些需求的实现。 | 需求 | 描述 | 由以下需求满足 | |---|---|---| | `[RS_SAFEX_00001]` | AUTOSAR 模型中可表达的安全需求 | `[TPS_SAFEX_00101]` | | `[RS_SAFEX_00002]` | 安全需求至少与其他需求一样具有表达力 | `[TPS_SAFEX_00101]` | | `[RS_SAFEX_00003]` | 通过 URI 描述的安全需求 | `[TPS_SAFEX_00105]` | | `[RS_SAFEX_00004]` | 可区分的安全需求 | `[TPS_SAFEX_00102]` | | `[RS_SAFEX_00005]` | 安全需求的唯一标识 | `[TPS_SAFEX_00103]` | | `[RS_SAFEX_00006]` | 安全需求的状态信息 | `[TPS_SAFEX_00104]` | | `[RS_SAFEX_00007]` | 安全需求的层次结构 | `[TPS_SAFEX_00301]` | | `[RS_SAFEX_00008]` | 安全需求的分解 | `[TPS_SAFEX_00302]` | | `[RS_SAFEX_00009]` | 独立性需求的规范 | `[TPS_SAFEX_00303]` | | `[RS_SAFEX_00010]` | 安全需求的 ASIL 属性 | `[TPS_SAFEX_00201]` | | `[RS_SAFEX_00011]` | AUTOSAR 元素的 ASIL 属性 | `[TPS_SAFEX_00202]` | | `[RS_SAFEX_00012]` | 安全需求的可追溯性 | `[TPS_SAFEX_00101]` | | `[RS_SAFEX_00013]` | 安全措施的可追溯性 | `[TPS_SAFEX_00401]` | | `[RS_SAFEX_00014]` | 安全需求的分配 | `[TPS_SAFEX_00306]`、`[TPS_SAFEX_00308]` | | `[RS_SAFEX_00015]` | AUTOSAR 模型中可表达的安全措施 | `[TPS_SAFEX_00401]` | | `[RS_SAFEX_00016]` | 安全措施的文本描述 | `[TPS_SAFEX_00401]` | | `[RS_SAFEX_00017]` | 安全措施的唯一标识 | `[TPS_SAFEX_00402]` | | `[RS_SAFEX_00018]` | 安全需求与安全措施之间的关系 | `[TPS_SAFEX_00307]` | | `[RS_SAFEX_00022]` | 安全措施的分配 | `[TPS_SAFEX_00305]`、`[TPS_SAFEX_00309]` | | `[RS_SAFEX_00023]` | 作为特殊安全措施的安全机制 | `[TPS_SAFEX_00401]` | --- ## 3 安全扩展概述 安全是汽车系统设计和开发中的关键问题之一。ISO 26262 [3] 定义了功能安全的当前标准，影响几乎所有的开发活动，包括软件规范、设计和实现。本文档支持在 AUTOSAR 上下文中标准化交换此类安全信息，并为 ISO 26262 要求的一致管理提供基础。 AUTOSAR 标准已经通过提供许多可用于实现安全软件的功能来解决功能安全问题，例如端到端保护、程序流监控、内存分区、用户 / 监督模式等（参见 [?, ] 以获取概述）。这些安全机制被视为 AUTOSAR 系统设计的组成部分。然而，ISO 26262 对功能安全软件开发的其他要求需要解决，特别是以下几点： - **安全需求** —— 与其他需求明确区分开来，并满足 ISO 26262 第 4 和 8 部分规定的要求（第 4 节）。 - **安全完整性等级** —— 对于每个 AUTOSAR 元素，遵循 ISO 26262-3 的模式（第 5 节）。 - **根据 ISO 26262-9 中给出的需求分解安全需求**（第 6 节）。 - **根据 ISO 26262 第 4、6 和 8 部分追溯和分配安全需求和安全措施**（第 6 节）。 - **ISO 26262-4 要求的安全措施和安全机制**（第 7 节）。这超出了 AUTOSAR 中存在的纯 SW 安全机制，并引入了一种抽象方式来引用系统架构的任何安全措施。 本规范遵循重用 AUTOSAR 可用文档功能的方法来解决这些需求。这意味着安全扩展定义了规则，通过使用现有的元模型概念（例如 `StructuredReq`、`TraceableText`、`trace`）来交换上述工作产品。因此，AUTOSAR 规范保持向后兼容，并且可以同时包含用于安全 SWC 开发和配置的统一的、工具可处理的安全信息（参见 RS-SafetyExtensions 需求 `[RS_SAFEX_00020]` 和 `[RS_SAFEX_00021]`）。 系统的安全需求层次结构（ISO 26262 中的项目开发）及其与 AUTOSAR 软件架构的关系如图 3.1 所示。安全需求的层次结构从为系统的危险 / 危险事件识别的安全目标开始。ASIL 作为属性在每个安全目标处维护，并通过后续级别的功能安全需求（作为 FSC 的一部分）和技术安全需求（作为 TSC 的一部分）一致地继承。后者将细化为 SW 和 HW 安全需求。 每个安全需求 1 必须正确分配给系统架构的元素，即组件、HW、SW 或两者（HW 和 SW）。因此，AUTOSAR 规范的元素可能会收到一个 ASIL，表明它处于 ISO 26262 开发的范围内。 > 1 功能安全需求被分配给更高级别的功能 / 逻辑架构。 **图 3.1**：安全需求的层次结构及其到系统架构元素的分配 在安全需求不可用或不会与规范一起交换的情况下，AUTOSAR 实现必须至少意识到该元素在安全上下文中使用。这是通过将 ASIL 属性附加到独立于分配的 AUTOSAR 元素来实现的。特别是在 SEooC 开发的情况下，即安全需求在开发时不完全已知，ASIL 属性通过将假设与最终确定的安全需求进行匹配来支持后续开发阶段此类部分的集成和验证。 从 AUTOSAR 元素的角度来看，分配的安全需求的实现通常依赖于系统上下文。例如，SWC 的实现者应知道底层处理器架构是否支持内存保护（例如通过 ECC / EDC / MMU / MPU），以便正确实现安全相关数据的处理。特别是安全需求到架构其他元素的分解和分配 —— 以及支持部件的约束和特征 —— 需要在开发时已知。对于大多数错误检测和错误处理、降级或时序方面，情况通常如此。例如，图 3.1 中的系统摘录表明外部 HW 看门狗的可用性，它可能是错误处理程序（例如截止时间或输出监控）中的支持元素。示例应用软件可能依赖于这种安全机制来处理组件本身无法检测的某些故障。 为了传递与 AUTOSAR 软件的开发、集成和配置相关的"安全上下文"相关信息，本规范除安全需求外，还提供了安全措施或安全机制的抽象。图 3.2 显示了软件堆栈和 / 或 ECU 硬件中可用不同安全机制的抽象概念。 **图 3.2**：安全措施、安全需求及其到架构元素的分配 如图所示，（分解的）安全需求首先映射到安全机制的抽象定义（此处：SM_E2E）。在后续步骤中，安全机制被分配给 AUTOSAR 模型的某些元素。如果安全机制代表任何其他技术，则此分配仅是隐式的（不属于 AUTOSAR）。这允许例如系统集成商验证分解中的免干扰是否在不同技术之间充分实现。请注意，此抽象也是有用的，例如，如果 AUTOSAR（实现）元素在 OEM 供应商之间的分布式工作中尚不可用，但系统工程师已经希望确定哪些方面以何种方式受到安全措施的保护。 定义安全需求或安全措施、分配安全需求等各个活动在 AUTOSAR 方法论中描述（参见 [4]）。因此，该方法论形式上满足了 [1] 中的需求 `[RS_SAFEX_00024]`。 --- ## 4 安全需求 本章定义如何将安全需求映射到 AUTOSAR 概念。基本上，安全需求遵循与正常需求相同的基本原理，但必须满足附加条件以符合 ISO 26262 需求（参见 [3] 第 8 部分第 6.4.2 条）。这主要包括在 AUTOSAR 中以以下方式处理的附加属性和特征： - **安全需求应被明确标识为安全需求**（参见 ISO 26262-8，第 6.4.2.1 条）。为此，需求通过由 `StructuredReq` 继承的 `category` 属性进行标记。 - **应提供安全需求到（软件）架构元素的分配信息**（参见 ISO 26262-8，第 6.4.2.3 条）。安全需求通过 `trace` 映射到 AUTOSAR 架构的任何对象。 - **安全需求应具有唯一标识**（ISO 26262-8，第 6.4.2.5.a 条），该标识在需求的整个生命周期中保持不变。本规范将对安全需求的 `shortName` 使用提出附加需求。 - **安全需求应具有状态属性**（ISO 26262-8，第 6.4.2.5.b 条）。状态属性不同于为需求定义的 AUTOSAR 生命周期信息，因此它映射到 `Sdg` 属性。 - **安全需求应具有 ASIL**（ISO 26262-8，第 6.4.2.5.c 条）。ASIL 属性映射到 `Sdg` 属性。 - **安全需求应沿设计级别按层次结构构建**，每个应维护对层次结构上一级的源的引用（ISO 26262-8，第 6.4.3.1 条和第 6.4.3.2 条）。由于 AUTOSAR 允许将需求追溯为 `TraceableText`，因此不需要扩展来表达这些层次依赖性。 - **如果应用 ASIL 分解**，则分解必须遵循 ISO 26262-9 第 5 条中定义的许多规则。本规范引入了一种特殊的 trace 类型，支持在每个安全需求上单独应用 ASIL 分解的概念。此外，ASIL 分解符号在 ASIL 属性中得到支持，例如 ASIL B(D)。 > **[TPS_SAFEX_00101]** 安全需求的描述 ⌈安全需求应使用 `[TPS_STDT_00060]` 中定义的 `StructuredReq` 作为正常需求进行描述。描述应包含需求的内容。⌋ > c(`RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00012`) 请注意，这无缝集成在 AUTOSAR 规范定义的文本可追溯性中。 > **[TPS_SAFEX_00103]** 安全需求的唯一标识符 ⌈安全需求应在 AUTOSAR 项目的范围内收到一个唯一 ID。该 ID 应作为 `shortName` 维护，以供进一步引用该需求，并对应于一般规则 `[TPS_GST_00021]`。⌋ > c(`RS_SAFEX_00005`) 请注意，安全需求标识符因此比 `[constr_2508]` 定义的正常短名称更严格。`shortName` 用作全局唯一 ID，类似于 [constr_2538] 中描述的其他元素的唯一性。此外，处理安全扩展的工具可以利用 `uuid` 属性来持久化工具相关的标识符。 > **[TPS_SAFEX_00102]** 安全需求的类型 ⌈安全需求应通过 `StructuredReq` 的 `category` 属性明确标记为安全需求，设置为以下之一： > - `SAFETY_GOAL` > - `SAFETY_FUNCTIONAL` > - `SAFETY_TECHNICAL` > - `SAFETY_SOFTWARE` > - `SAFETY_HARDWARE` > - `SAFETY_EXTERNAL` > > 这些值在安全上下文中扩展了 [2] 中 [constr_2540] 中定义的值。⌋ > c(`RS_SAFEX_00004`) ASIL 属性在 `[TPS_SAFEX_00201]` 中定义。 > **[TPS_SAFEX_00104]** 状态属性 ⌈安全需求应作为包含 `Sdg` 数据字段（`gid="SAFEX"`）的 `AdminData` 接收状态属性。XML 内容应包含一个具有属性 `gid="STATUS"` 的 `Sd` 元素。⌋ > c(`RS_SAFEX_00006`) 状态属性的值未规定，是实现特定的。 出于各种原因，在 AUTOSAR 项目和 / 或一组 AUTOSAR XML 文档的范围内交换整个安全需求层次结构是不可行的。例如，对 HW 安全需求或安全目标的引用可能被有意排除，或者安全需求可能驻留在需求数据库中。为了支持链接此类驻留在 AUTOSAR 之外的安全需求，本规范引入了**外部安全需求**的概念。 > **[TPS_SAFEX_00105]** 外部安全需求 ⌈应作为引用包含在 AUTOSAR 文档中的外部安全需求应标记为 `category` 设置为 `SAFETY_EXTERNAL`，且描述应仅包含到安全需求所在位置的 Xfile URI。⌋ > c(`RS_SAFEX_00003`) 可选地，可以根据 `[TPS_SAFEX_00201]` 和 `[TPS_SAFEX_00104]` 中的定义设置（缓存）ASIL 和 / 或状态属性以及 `tool` 和 `toolVersion`，以方便使用。 下面的列表显示了安全需求如何在 AUTOSAR XML 中表达的示例（注：此列表包含从本文档后续章节中引入的规范项派生的元素）： **列表 4.1**：AUTOSAR XML 中安全需求的表示 ```xml SysSafReq05 CL15_ON light switch HW lib SAFETY_TECHNICAL B PROPOSED FSR02 Valid

当 CL15ON==1 时，FLM ECU 仅在 HW_LB==1 条件连续 20 ms 为真时才应关闭灯。（CAN 消息：CL15_01 CAN 信号：CL15ON 布尔值，'1' 表示 clamp 15 设置为 on，'0' 表示 clamp 15 设置为 off）

SysSafReq42 SAFETY_EXTERNAL C ACCEPTED FSR02 Valid

SysSafReq42 http://requirements.mycompany.com:6777/db/prj/safety/SysSafReq42 My Requirements Tool 9.3.1

``` --- ## 5 安全完整性等级 本规范旨在支持 ISO 26262 [3] 的汽车安全完整性等级（ASIL）。其他安全完整性等级将不被考虑，并不在本文档的范围内。 ASIL 作为 ISO 26262-3 概念阶段中 HARA 的一部分确定，并分配给每个安全目标。系统设计 —— 最终是软件架构 —— 将通过安全需求到技术 / 软件架构的分配（参见第 3 节，详见第 6 节对安全需求的分配）将此 ASIL 作为属性继承。 > **[TPS_SAFEX_00201]** 安全需求的 ASIL 属性 ⌈根据第 4 节定义的安全需求应接收 ASIL 属性。ASIL 存储在包含 `Sdg` 数据（`gid="SAFEX"`）的 `AdminData` 中。此元素的内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素。此属性的有效值为： > - `QM` > - `A` > - `B` > - `C` > - `D` > - `QM(A)` > - `QM(B)` > - `QM(C)` > - `QM(D)` > - `A(B)` > - `A(C)` > - `A(D)` > - `B(B)` > - `B(C)` > - `B(D)` > - `C(C)` > - `C(D)` > - `D(D)` > ⌋ > c(`RS_SAFEX_00010`) 请注意，括号表示法用于表示分解的安全需求。在本规范中，我们将原始 ASIL（即括号中的值）称为分解前的上下文 ASIL，因为它属于安全目标的上下文。 > **[constr_6200]** 安全目标没有分解的 ASIL ⌈如果安全需求的类型为 `SAFETY_GOAL`，则 ASIL 属性的有效值限制为：`QM`、`A`、`B`、`C` 或 `D`。⌋ > c() > **[TPS_SAFEX_00202]** AUTOSAR 元素的 ASIL（可选） ⌈如果至少有一个安全需求被分配给某个 AUTOSAR 元素，则该元素应接收 ASIL 属性。ASIL 应作为 `Sdg` 数据（`gid="SAFEX"`）添加到 XML 的 `AdminData` 部分。XML 内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素，有效值与 `[TPS_SAFEX_00201]` 中相同。⌋ > c(`RS_SAFEX_00011`) 请注意，根据 `[TPS_SAFEX_00202]`，元素的 ASIL 是可选的。1 如果未在元素处指定 ASIL，则其语义是从所有已分配的安全需求中派生为最高 ASIL。 > 1 这在 SEooC 或延续开发中可能很有用，其中现有规范在实施后与安全需求连接。 > **[constr_6201]** ASIL 值的一致性 ⌈AUTOSAR 元素的 ASIL 和已分配的安全需求应一致。如果元素处的值等于或高于已分配安全需求的最大 ASIL，则 ASIL 是一致的。⌋ > c() 请注意，出于各种原因，AUTOSAR 元素的 ASIL 可能高于安全需求的 ASIL。例如，SWC 可能被设计用于在更高的安全完整性上下文中重用，因此被评级为更高的 ASIL。然而，对于分解的需求，上下文 ASIL 如何在 ASIL 值的比较中加以考虑是开放的解释。 有关安全需求处 ASIL 属性的示例，请参见列表 4.1。 **列表 5.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例 ```xml MyComponent B [...] ``` --- ## 6 安全需求的可追溯性与分配 ISO 26262 中安全需求的基本特征是追溯的管理和维护。本规范将安全需求的可追溯性称为（安全）需求与其他元素之间不同类型链接的通用术语。主要区分三种类型的 trace： 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` 元素）管理。 分解是细化关系的专门化，具有架构含义。安全需求的分解需要系统架构中存在两个独立的元素，对于这些元素可以保证免干扰。为了通过分解的安全需求向下追溯到软件，我们正在提高实现者的意识，并支持在集成测试期间验证相同的内容。 > **[TPS_SAFEX_00301]** 安全需求的细化关系 ⌈安全需求的细化关系应通过 trace 关联表达。trace 的方向具有语义"refines"。⌋ > c(`RS_SAFEX_00007`) > **[TPS_SAFEX_00302]** 安全需求的分解 ⌈分解应在将安全需求分解为的两个分解需求中的每一个处指定。为此，这两个分解需求都应接收一个 `AdminData` 条目，其中包含一个名为 `gid="DECOMPOSITION"` 的 `Sdg` 元素，该元素具有对分解的安全需求的 `sdx`（即 `Referrable`）引用。⌋ > c(`RS_SAFEX_00008`) > **[constr_6202]** 分解为两个安全需求 ⌈由 `[TPS_SAFEX_00302]` 指定的分解应针对每个分解需求恰好在两个分解安全需求（不多）处指定。⌋ > c() > **[constr_6203]** 仅分解一个安全需求 ⌈根据 `[TPS_SAFEX_00302]` 指定的每个分解需求最多分解一个其他需求。⌋ > c() > **[TPS_SAFEX_00303]** 独立性需求链接 ⌈如果安全需求表达了实现分解元素免干扰的手段，则它们应附加于分解需求，在两个分解安全需求处列出。因此，每个分解安全需求的 `AdminData` 在具有 `gid="INDEPENDENCE"` 的 `Sdg` 元素中接收一个单独的引用（`sdx` 条目）。⌋ > c(`RS_SAFEX_00009`) 请注意，分解的安全需求和独立性需求可以另外接收指向分解安全需求的"反向"trace。这样，整个可追溯性层次结构可以由不感知安全扩展的工具无缝导航。 > **[TPS_SAFEX_00306]** 安全需求到 AUTOSAR 元素的分配 ⌈安全需求到 AUTOSAR 元素的分配通过 `AdminData` 块中指向 AUTOSAR 元素的引用来表达。对于每个分配引用，应在名为 `gid="ALLOCATION"` 的组合 `Sdg` 元素中列出 `sdx` 引用。⌋ > c(`RS_SAFEX_00014`) 安全需求到 AUTOSAR 元素的直接分配的替代方案是首先映射到安全措施（如果适用），然后再映射到 AUTOSAR 元素。例如，确保安全通信的安全需求可以映射到安全机制"端到端保护"，而后者又被分配给端到端配置文件。 > **[TPS_SAFEX_00305]** 安全需求到安全措施的映射 ⌈安全需求到安全措施的分配应映射到具有名称 `gid="MAPS_TO"` 的 `Sdg` 元素（在 `AdminData` 块中）中的 `sdx` 引用，其中包含指向安全措施的 `sdx` 引用。⌋ > c(`RS_SAFEX_00022`) 作为完全等效的替代方案，安全机制可以包含指向其将实现的安全需求的反向链接： > **[TPS_SAFEX_00309]** 映射关系的替代关系 ⌈映射关系应由从安全措施到安全需求的 trace 关联表达。trace 的方向具有语义"realizes"。⌋ > c(`RS_SAFEX_00022`) > **[TPS_SAFEX_00307]** 安全措施到 AUTOSAR 元素的分配 ⌈安全措施到一个（或多个）AUTOSAR 元素的映射应在包含名为 `gid="ALLOCATION"` 的 `Sdg`（包含指向 AUTOSAR 元素的 `sdx` 引用）的 `AdminData` 中表达。⌋ > c(`RS_SAFEX_00018`) 从 AUTOSAR 元素的角度来看，分配链接具有"realizes"（或"satisfies"）语义：元素必须实现所有已分配的安全需求和定义的安全机制。因此，本规范通过 realizes 关系提供了这些关系的完全等效替代方案：1 > 1 这在（安全）需求规范已建立基线且不应更改的情况下可能很有用。 > **[TPS_SAFEX_00308]** AUTOSAR 元素的 realizes 关系 ⌈安全需求或安全措施的分配可以通过 realizes 引用表达。引用应作为 `Sdg` 数据添加到元素的 `AdminData` 部分，属性为 `gid="REALIZES"`。XML 内容应包含一个 `Sd` 元素，其中包含引用已分配安全需求的 `sdx` 引用列表。⌋ > c(`RS_SAFEX_00014`) **列表 6.1**：realizes 关系的 AUTOSAR XML 表示示例 ```xml [...] FLM_swc FLM B ECU_TSR_03 [...] ``` **列表 6.2**：各种 trace 关系的 AUTOSAR XML 表示 ```xml ECU_TSR_01 确保 CAN 消息已接收 SAFETY_TECHNICAL B PROPOSED SysSafReq05 SysSafReq03 SysSafReq47 Valid

CAN 消息 CAN BUS CAN_CL15 应被正确接收。

... ECU_TSR_03 确保正确的 CAN 总线消息转换 SAFETY_TECHNICAL QM(B) PROPOSED ECU_TSR_01 ECU_TSR_047 /FLM_pkg/FLM_swc/FLM ... ECU_TSR_05 CL15_ON 故障检查 SAFETY_TECHNICAL B(B) PROPOSED ECU_TSR_01 ECU_TSR_047 SM_E2E ... ECU_TSR_047 信号处理中的免干扰 SAFETY_TECHNICAL ... ``` --- ## 7 安全措施 系统的安全是通过在开发过程的各个阶段应用的安全措施以及在系统中通过多种技术实现的安全机制来实现的。本规范出于多种原因考虑了超出纯 AUTOSAR 软件堆栈范围的安全措施： - **软件安全通常依赖于（外部）硬件机制来实现其安全完整性**，例如内存保护和分区、ECC / EDC、锁步模式、外部看门狗等。在实施过程中，这些上下文依赖性应明确成为任何软件的"运行时契约"的一部分，而不仅仅是隐式通信。 - **错误检测和错误处理通常涉及 SW 和 HW 之间复杂的交互**，从监控到中断和处理例程，再到执行器的关闭路径。因此，任何软件安全机制都应感知技术环境、系统级别的安全状态、潜在的故障和 HW 所隐含的约束。 - **软件集成需要验证安全机制的有效性**。如果软件规范说明了实现哪些安全机制或执行了哪些措施，则一致性检查和（半）自动验证成为可能，这反过来又减少了系统性失效。 - **最后，任何软件都受到运行它的 HW / 平台的影响**。理解和避免（系统性）失效只有在系统级别对安全机制的意图被记录、可访问并被实施者很好地理解的情况下才有可能。 AUTOSAR 已经提供了许多可用于实现安全软件的安全机制和功能，例如端到端保护、程序流监控、看门狗管理器等（参见 [?, ] 以获取概述）。这些功能可以用作 `[TPS_SAFEX_00305]` 映射的目标。请注意，除本节中的需求外，本规范不对文本描述施加任何约束。 > **[TPS_SAFEX_00401]** 安全措施或安全机制的定义 ⌈安全措施（或安全机制）应描述为 `TraceableText`。`category` 属性应使用 `SAFETY_MEASURE` 或 `SAFETY_MECHANISM` 标记文本块。⌋ > c(`RS_SAFEX_00013`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00023`) > **[TPS_SAFEX_00402]** 安全措施的唯一标识符 ⌈安全措施 / 机制应作为 `shortName` 接收唯一标识符。该 ID 在 AUTOSAR 项目的范围内应是唯一的。⌋ > c(`RS_SAFEX_00017`) **列表 7.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例 ```xml SM_E2E 信号 CL15ON 的端到端保护 SAFETY_MECHANISM /FLM_swc/FLM/MyEnd2EndProfile

E2E 通信保护，使发送方能够保护数据，接收方能够在运行时检测错误并处理它们

``` --- ## 8 应用说明 当前版本的本规范没有具体的应用说明。 --- ## 附录 A 提到的类表 为完整起见，本章包含一组表示本文档上下文中提到的元类的类表，但不直接包含在描述特定元模型语义的范围内。 > **翻译说明**：本附录列出 11 个 AUTOSAR 元类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），包含每个类的属性定义。由于这些是标准 AUTOSAR 元模型参考表，本翻译仅翻译前 3 个表的概要信息；完整定义请参见原文 PDF 第 28-35 页。 ### 表 A.1: `AdminData` | 属性 | 类型 | 多重性 | 种类 | 说明 | |---|---|---|---|---| | `docRevision` | `DocRevision` | * | 聚合 | 表示有关对象当前修订的信息。 | | `language` | `LEnum` | 0..1 | 属性 | 指定文档或文档片段的主语言。 | | `sdg` | `Sdg` | * | 聚合 | 允许保留标准模型未表示的特殊数据。 | | `usedLanguages` | `MultiLanguagePlainText` | 0..1 | 聚合 | 指定文档中提供的语言。 | > **摘要标记**：附录 A 包含 11 个类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），每个类表描述标准 AUTOSAR 元模型参考类。本翻译仅翻译 `AdminData` 表的概要；其他类表的详细属性请参见原文 PDF 第 28-35 页。 --- ## 翻译说明 - **翻译完整性**：本文档为 AUTOSAR 安全扩展模板规范（TPS）的中文翻译版本，完整翻译了 1-8 章及附录 A 的概要内容。 - **保留的英文术语**：所有规范项 ID（`TPS_SAFEX_xxxxx`、`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`constr_xxxx`）、AUTOSAR 元模型类名（`StructuredReq`、`TraceableText`、`AdminData`、`Identifiable`、`Referrable`、`Sdg`、`Sd`、`Xfile` 等）、属性名（`category`、`shortName`、`longName`、`trace`、`desc` 等）、ASIL 等级（QM、A、B、C、D 及其分解表示）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。 - **省略的内容**：免责声明（Disclaimer）按要求未翻译。 - **关键概念**： - **安全扩展元模型概念**：使用 `Sdg`（Special Data Group）和 `Sd`（Special Data）属性来附加 ASIL、状态、分解、分配等安全信息。 - **安全需求类别**：`SAFETY_GOAL`、`SAFETY_FUNCTIONAL`、`SAFETY_TECHNICAL`、`SAFETY_SOFTWARE`、`SAFETY_HARDWARE`、`SAFETY_EXTERNAL`。 - **安全措施与安全机制**：使用 `SAFETY_MEASURE` 和 `SAFETY_MECHANISM` 类别标记。 - **ASIL 分解表示**：括号表示法，例如 ASIL B(D) 表示原始 ASIL 为 D，分解后为 B。 - **追溯关系类型**：`trace`（细化）、`DECOMPOSITION`（分解）、`INDEPENDENCE`（独立性）、`ALLOCATION`（分配）、`MAPS_TO`（映射到）、`REALIZES`（实现）。 - **附录摘要**：附录 A 列出 11 个 AUTOSAR 元类参考表，已翻译首张表，其余详见原文。