AUTOSAR_TPS_SafetyExtensions 中文翻译

文档编号：671　|　状态：Final（正式发布）　|　发布于：AUTOSAR CP Release 4.4.0（2018-10-31）
所属标准：AUTOSAR Classic Platform 标准　|　文档责任方：AUTOSAR　|　保密等级：AUTOSAR CONFIDENTIAL

本翻译覆盖原文档 1-35 页正文，约 0.44 MB / 35 页。
原文为模板规约（TPS, Template Specification），定义 AUTOSAR 安全扩展（Safety Extensions）的元模型规约与结构化需求（StructuredReq）的安全属性映射规则。
本翻译校对区块：7 章 + 7 项 TPS_SAFEX_NNNNN 规范项 + 17 个唯一规范项 ID + 完整 RS_SAFEX → TPS_SAFEX 追溯表（19 行） + 9 项缩略语 + 5 项术语 + 4 项参考文献 + 1 个 ARXML 代码示例。

1 引言（Introduction）

1.1 概述（Overview）

本文档包含 AUTOSAR 安全扩展（Safety Extensions）的规约，并实现 [1] 中陈述的需求。安全扩展通过现有（通用）AUTOSAR 元模型概念表达。在后续版本中可能会引入原生元模型概念。第 3 节对这些扩展提供更详细的概述。

1.2 范围（Scope）

本文档的范围涵盖应在 AUTOSAR 上下文中使能 ISO 26262 开发的安全扩展。这些扩展允许安全信息的标准化交换，并为不同厂商与工具之间的一致管理提供基础（按 ISO 26262 要求）。

本文档不是关于功能安全或 ISO 26262 的一般性介绍。其他安全标准或指南（如 IEC 61508、MISRA）不在范围内。

1.3 文档约定（Document Conventions）

AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格格式（参见 AUTOSAR_TPS_StandardizationTemplate [2]，Support for Traceability 章节）。用以表达义务的措辞形式遵循 [TPS_STDT_00053]（参见 [2]）：SHALL/SHALL NOT/SHOULD/MAY/OPTIONAL 等关键字保留英文原意并首次出现时附中文释义。

1.4 缩略语（Abbreviations）

表 1.1：缩略语

1.5 术语表（Glossary of Terms）

本文档将使用 ISO 26262-1 [3] 中定义的安全相关术语。为澄清起见，表 1.2 列出与 AUTOSAR 相关的部分术语定义：

表 1.2：术语表

1.6 指南（Guidelines）

已存在的规范应以单一需求形式被引用。与这些规范的差异应作为附加需求指定。所有需求应具备以下属性：

• 冗余性（Redundancy）：需求不应在单个需求中或其他需求中重复；
• 清晰性（Clearness）：所有需求应仅允许一种解释；不在术语表中的技术术语须明确定义；
• 原子性（Atomicity）：每条需求应仅包含一个需求；
• 可测试性（Testability）：需求应可通过分析、评审或测试验证；
• 可追溯性（Traceability）：需求的来源与状态应始终可见。

2 需求追溯（Requirements Tracing）

下表引用 [1]（AUTOSAR_RS_SafetyExtensions）中规约的需求，并链接到本 TPS 中对这些需求的实现：

追溯表共 19 行 RS_SAFEX_NNNNN 上级需求；链接 1-2 个 TPS_SAFEX_* 规范项 ID；下游规范项 ID 唯一集合 = {00101, 00102, 00103, 00104, 00105, 00201, 00202, 00301, 00302, 00303, 00305, 00306, 00307, 00308, 00309, 00401, 00402} 共 17 个 ID。

3 安全扩展概述（Safety Extensions Overview）

安全是汽车系统设计与开发中的关键问题之一。ISO 26262 [3] 定义了功能安全的当前标准，其影响几乎所有开发活动，包括软件规约、设计与实现。本文档使能在 AUTOSAR 上下文中安全信息的标准化交换，并为 ISO 26262 要求的一致管理提供基础。

AUTOSAR 标准已通过提供多种可用于实现安全软件的特性来应对功能安全，例如端到端保护（E2E）、程序流监控、内存分区、用户/监控模式等（详见 [EXP_FunctionalSafetyMeasures]）。这些安全机制被识别为 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 中的 item 开发）及其与 AUTOSAR 软件架构的关系见图 3.1（原文 p.11）。安全需求层次结构从针对系统危险/危险事件识别的安全目标（Safety Goals）开始。ASIL 作为属性在每个安全目标处维护，并通过后续层级一致继承：功能安全需求（FSC 的一部分）和技术安全需求（TSC 的一部分）。后者将被细化为 SW 与 HW 安全需求。

每个安全需求必须被正确分配到系统架构的元素，即组件、HW、SW 或两者（HW 和 SW）。因此，AUTOSAR 规约的元素可能接收一个 ASIL，指示其属于 ISO 26262 开发的范围。

在安全需求不可用或不会随规约交换的情况下，AUTOSAR 实现必须至少知道该元素用于安全上下文。这是通过将 ASIL 属性附加到独立于分配的 AUTOSAR 元素来实现的。特别是在 SEooC 开发情况下（其中安全需求在开发时未完全已知），ASIL 属性通过将假设与最终化安全需求进行匹配来支持这些部分在开发后期的集成与验证。

从 AUTOSAR 元素视角看，分配的安全需求的实现通常依赖于系统上下文。例如，SWC 的实现者应知道底层处理器架构是否支持内存保护（如 ECC/EDC/MMU/MPU），以正确实现安全相关数据的处理。尤其是安全需求到架构其他元素的分解与分配——以及支持部分的约束与特性——需要在开发时已知。这通常适用于大多数错误检测与错误处理、降级或时序方面。例如，图 3.1 中的系统摘录指示外部 HW 看门狗的可用性，这可能是错误处理过程（如截止期或输出监控）中的支持元素。示例应用软件可能依赖此安全机制以应对组件本身无法检测的某些失效。

为了传达开发、集成与配置 AUTOSAR 软件所需的此"安全上下文"相关信息，本规约除安全需求外还提供了安全措施或安全机制的抽象。图 3.2 展示了软件栈和/或 ECU 硬件中可用不同安全机制的抽象概念。

如图所示，（分解的）安全需求首先被映射到安全机制的抽象定义（此处：SM_E2E）。在后续步骤中，安全机制被分配到 AUTOSAR 模型的某些元素。在安全机制表示任何其他技术的情况下，此分配仅为隐式（不作为 AUTOSAR 的一部分）。这允许例如系统集成商验证分解中跨不同技术的抗干扰性是否充分实现。注意此抽象也是有用的，例如 AUTOSAR（实现）元素在 OEM 与供应商的分布式工作中尚不可用的情况下，但系统工程师希望已确定哪些方面以何种方式被安全措施保护。

定义安全需求或安全措施、分配安全需求等的各活动在 AUTOSAR 方法学（参见 [4]）中描述。因此，方法学正式地处理 [1] 的需求 [RS_SAFEX_00024]。

4 安全需求（Safety Requirements）

本章定义安全需求如何映射到 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 使用提出附加需求。
• 安全需求应具有 status 属性（ISO 26262-8 第 6.4.2.5.b 条款）。status 属性不同于为需求定义的 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)。

下面的列表展示如何在 AUTOSAR XML 中表达安全需求的示例（注：本列表包含来自本文档后续章节中引入的规约项的元素）：

<!-- A technical safety requirement -->
<STRUCTURED-REQ>
  <SHORT-NAME>SysSafReq05</SHORT-NAME>
  <LONG-NAME>
    <L-4 L="EN">CL15_ON light switch HW lib</L-4>
  </LONG-NAME>
  <CATEGORY>SAFETY_TECHNICAL</CATEGORY>
  <ADMIN-DATA>
    <SDGS>
      <SDG GID="SAFEX">
        <SD GID="ASIL">B</SD>
        <SD GID="STATUS">PROPOSED</SD>
      </SDG>
    </SDGS>
  </ADMIN-DATA>
  <TRACE-REFS>
    <!-- Traceability link to upper hierarchy (here: functional safety
         requirement; alternatively external safety requirement via Xfile) -->
    <TRACE-REF>...</TRACE-REF>
  </TRACE-REFS>
  <!-- Refinement / Decomposition links -->
  <TRACE-REFS>
    <!-- either <REFINEMENT> or <DECOMPOSITION> (traces) -->
  </TRACE-REFS>
</STRUCTURED-REQ>

列表 4.1：安全需求的 AUTOSAR XML 表示

5 安全完整性等级（Safety Integrity Levels）

本规约旨在支持 ISO 26262 [3] 的汽车安全完整性等级（ASIL）。其他安全完整性等级不被考虑，不在本文件范围内。

ASIL 作为 ISO 26262-3 概念阶段中 HARA 的一部分确定，并分配给每个安全目标。系统设计——最终是软件架构——将通过安全需求到技术/软件架构的分配来继承此 ASIL 属性（参见第 3 节，详见第 6 节关于安全需求的分配）。

安全需求上 ASIL 属性的示例参见列表 4.1。

<!-- Example AUTOSAR element with ASIL -->
<APPLICATION-SW-COMPONENT-TYPE>
  <SHORT-NAME>MyComponent</SHORT-NAME>
  <ADMIN-DATA>
    <SDGS>
      <SDG GID="SAFEX">
        <SD GID="ASIL">B</SD>
      </SDG>
    </SDGS>
  </ADMIN-DATA>
  <PORTS>
    [...]

列表 5.1：元素上 ASIL 属性的 AUTOSAR XML 表示示例

6 安全需求可追溯性与分配（Safety Requirements Traceability and Allocation）

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

1. 精化关系（Refinement relations）：在两个层级安全需求之间，例如有助于功能安全需求的技术安全需求（参见 ISO 26262-8 第 6.4.3.1.a 条款）。此概念类似于 AUTOSAR 规约本身的上游追溯，并将以相同方式实现。
2. 分配关系（Allocation relations）：从安全需求到软件架构元素，例如分配到 AUTOSAR SWC 端口的 SW 安全需求（参见 ISO 26262-8 第 6.4.2.3 条款）。
3. 映射关系（Mapping relations）：从安全需求到安全措施/机制，例如映射到端到端保护安全机制的 CRC 安全需求（参见 ISO 26262-4 第 6.4.1、6.4.2、6.4.6 条款）。

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

分解（Decomposition）是精化关系的一种特化，具有架构含义。安全需求的分解要求系统架构中存在两个独立元素，可以保证抗干扰。为了通过分解后的安全需求向下追溯到软件，我们提升实现者的意识并使集成测试期间的验证成为可能。

列表 6.1：realizes 关系的 AUTOSAR XML 表示示例：

[...]
<AR-PACKAGE>
  <SHORT-NAME>FLM_swc</SHORT-NAME>
  <ELEMENTS>
    <APPLICATION-SW-COMPONENT-TYPE>
      <SHORT-NAME>FLM</SHORT-NAME>
      <ADMIN-DATA>
        <SDGS>
          <SDG GID="ASIL">
            <SD>B</SD>
          </SDG>
          <!-- Example showing the <<realizes>> relationship (cp. TPS_SAFEX_00308) -->
          <SDG GID="REALIZES">
            <SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_03</SDX-REF>
          </SDG>
        </SDGS>
      </ADMIN-DATA>
    [...]

7 安全措施（Safety Measures）

本章定义如何在 AUTOSAR 模型中表达安全措施与安全机制。从视角看，安全措施和/或安全机制是实现若干安全需求的处理过程或技术。安全措施在 AUTOSAR 中被定义为特殊 TraceableText 元素，category 为 SAFETY_MEASURE 或 SAFETY_MECHANISM。

包含安全措施与/或安全机制的动机：

• 若安全措施被显式建模为 AUTOSAR 中的对象，则可与安全需求建立清晰关联，便于检查实现完整性；
• 若安全措施与具体实现或被执行的措施相关联，一致性检查与（半）自动验证成为可能，进而减少系统性失效；
• 最后，任何软件都受运行它的 HW/平台影响。理解并避免（系统性）失效仅在系统层级预期的安全机制被记录、可访问并被实现者良好理解时才是可能的。

AUTOSAR 已提供多种可用于实现安全软件的安全机制与特性，例如端到端保护、程序流监控、看门狗管理器等（详见 [EXP_FunctionalSafetyMeasures]）。这些特性可用作 [TPS_SAFEX_00305] 映射的目标。注意：本规约不对文本描述规定任何约束，除本节中的需求外。

列表 7.1：安全机制上 ASIL 属性的 AUTOSAR XML 表示示例：

<!-- Example safety mechanism -->
<TRACE>
  <SHORT-NAME>SM_E2E</SHORT-NAME>
  <LONG-NAME>
    <L-4 L="EN">End to End protection of the signal CL15ON</L-4>
  </LONG-NAME>
  <CATEGORY>SAFETY_MECHANISM</CATEGORY>
  <ADMIN-DATA>
    <SDGS>
      <SDG GID="ALLOCATION">
        <SDX-REF DEST="END-TO-END-PROTECTION-SET" BASE="FLM_swc">/FLM_swc/FLM/MyEnd2EndProfile</SDX-REF>
      </SDG>
    </SDGS>
  </ADMIN-DATA>
  <P>
    <L-1 L="EN">E2E communication protection enabling the sender to protect data and the receiver to detect errors and handle them at runtime</L-1>
  </P>
</TRACE>

8 应用笔记（Application Notes）

本规约当前版本无特定的应用笔记。

附录 A：引用的类表（Mentioned Class Tables）

为完整性起见，本章包含一组类表，表示在本文档上下文中被提及的元类，但不直接包含在描述特定元模型语义的范围内。

A.1 AdminData 类

表 A.1：AdminData

A.2 Identifiable 抽象类

表 A.2：Identifiable（抽象）

参考文献（References）

1. AUTOSAR_RS_SafetyExtensions — 安全扩展需求（Requirements on Safety Extensions）
2. AUTOSAR_TPS_StandardizationTemplate — 标准化模板（Standardization Template）
3. ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition（ISO 26262 第 1-10 部分——道路车辆——功能安全，第一版）；http://www.iso.org
4. AUTOSAR_TR_Methodology — AUTOSAR 方法学（Methodology）